Sözleşme Geliştirmenin Harika İpuçları: Uniswap Kodundan Öğrenilen Deneyimler
Son zamanlarda merkeziyetsiz borsa geliştirme kılavuzunu yazarken, tanınmış bir DEX'in kod uygulamasını referans aldım ve birçok yeni bilgi edindim. Daha önce basit bir NFT sözleşmesi geliştirmiş bir geliştirici olarak, bu benim Defi sözleşmesi geliştirme konusundaki ilk denemem. Bu küçük ipuçlarının sözleşme geliştirmeyi öğrenmek isteyen yeni başlayanlar için çok faydalı olacağına inanıyorum.
Şimdi bu ilginç ipuçlarına birlikte bakalım, bazıları hatta tuhaf beceriler olarak adlandırılabilir.
Tahmin Edilebilir Sözleşme Dağıtım Adresi
Genellikle bir sözleşme dağıtıldığında, nonce ile ilişkili olduğu için görünüşte rastgele bir adres elde edilir, bu nedenle sözleşme adresini tahmin etmek zordur. Ancak belirli senaryolar altında, işlem çiftleri ve ilgili bilgiler aracılığıyla sözleşme adresini çıkarmamız gerekebilir. Bu, birçok durumda çok kullanışlıdır, örneğin işlem yetkilerini değerlendirmek veya likidite havuzu adresini almak gibi.
CREATE2 yöntemi ile sözleşme oluşturmak için salt parametresi ekleyerek sözleşme oluşturabilirsiniz, böylece oluşturulan sözleşme adresi tahmin edilebilir. Adres oluşturma mantığı şudur: Yeni adres = hash("0xFF", oluşturucu adresi, salt, initcode).
Geri çağırma fonksiyonlarını iyi kullanma
Solidity'de, sözleşmeler birbirlerini çağırabilir. Bir senaryo, A'nın bir metodunda B'yi çağırmasıdır, B çağrıldığı metodun içinde A'ya geri çağrıda bulunur, bu bazı senaryolarda oldukça kullanışlıdır.
Örneğin, bir DEX sözleşmesinin swap yöntemini çağırdığınızda, swapCallback geri çağrılır ve bu işlem için hesaplanan gerçek Token iletilir. Çağıran taraf, geri çağırma sırasında gereken Token'ı DEX sözleşmesine transfer etmelidir, swap yöntemini iki parçaya ayırıp çağıran tarafın çağırmasını sağlamamalıdır. Bu, swap yönteminin güvenliğini garanti eder, tüm mantığın eksiksiz bir şekilde yürütülmesini sağlar ve güvenliği sağlamak için karmaşık değişken kayıtlarına gerek kalmaz.
İstisna ile bilgi iletimi, işlem tahmini için try catch kullanımı
Bazı DEX'in kodunda, swap metodunun try catch ile sarmalanarak çalıştırıldığını gördük. Bunun sebebi nedir? Çünkü swap metodunu simüle ederek işlem için gerekli Token'ı tahmin etmemiz gerekiyor, ancak tahmin sırasında gerçekten Token değişimi gerçekleşmeyeceğinden hata veriyor. İşlem geri çağırma fonksiyonu içinde özel bir hata fırlatarak, bu hatayı yakalıyor ve hata mesajından gerekli bilgileri ayrıştırıyor.
Bu biraz hileli görünüyor ama çok pratiktir. Bu sayede tahmin edilen ticaret talebini karşılamak için takas yöntemini değiştirmeye gerek kalmıyor, mantık da daha basit.
Büyük Sayılar ile Hassasiyet Problemini Çözmek
DEX kodunda birçok hesaplama mantığı vardır, örneğin mevcut fiyat ve likiditeye göre takas edilen Token'ı hesaplamak. Bu süreçte, bölme işlemi sırasında hassasiyet kaybını önlememiz gerekiyor. Bazı uygulamalarda, hesaplama süreci sık sık "<< FixedPoint96.RESOLUTION" işlemini kullanır; bu, 96 bit sola kaydırmayı temsil eder ve 2^96 ile çarpmaya eşdeğerdir. Sola kaydırdıktan sonra bölme işlemi yaparak, normal işlemlerde taşma olmadan ( genellikle uint256 ile hesaplanır, bu sayede ) durumunda hassasiyet garanti edilir.
Share Yöntemi ile Kazancı Hesaplama
DEX'te, LP( likidite sağlayıcısı )'in işlem ücretlerini kaydetmemiz gerekiyor. Açıkça, her işlemde her LP'nin kendi işlem ücretini kaydetmek mümkün değil, bu çok fazla Gas tüketir. Peki, bu durumda ne yapmalıyız?
Position içinde feeGrowthInside0LastX128 ve feeGrowthInside1LastX128 içeren bir yapı tanımlanabilir; bunlar, her pozisyonda son komisyon çekiminde her likiditenin alması gereken komisyonu kaydeder.
Kısaca, toplam işlem ücretini ve her bir likiditenin alması gereken işlem ücretini kaydetmek yeterlidir. LP, işlem ücretini çekerken, sahip olduğu likiditeye göre çekebileceği işlem ücretini hesaplayabilir. Bu, bir şirketin hisse senedine sahip olmaya benzer; hisse senedi gelirini çekerken yalnızca şirketin tarihi hisse başına kazancını ve en son çektiğinizdeki kazancı bilmeniz yeterlidir.
Tüm bilgilerin zincir üzerinden alınması gerekmez
Blok zincirinde depolama görece pahalıdır, bu nedenle tüm bilgilerin zincire alınması veya zincirden alınması gerekmez. Örneğin, bazı DEX ön yüz web sitelerinin çağırdığı birçok arayüz, geleneksel Web2 arayüzleridir.
Ticaret havuzları listesi, ticaret havuzu bilgileri vb. normal bir veritabanında saklanabilir, bazıları zincirden düzenli olarak senkronize edilmesi gerekebilir, ancak ilgili verileri almak için zincir veya düğüm hizmetleri tarafından sağlanan RPC arayüzünü gerçek zamanlı olarak çağırmak gerekmez.
Elbette, ana işlemler kesinlikle zincir üzerinde gerçekleştirilecektir.
Sözleşme bölmeyi öğrenin, mevcut standart sözleşmeleri kullanın
Bir proje birden fazla gerçek dağıtılmış sözleşme içerebilir. Gerçek dağıtımda yalnızca bir sözleşme olsa bile, sözleşmeyi miras alma yöntemiyle birden fazla sözleşmeye ayırarak bakımını yapabiliriz.
Ayrıca, @openzeppelin/contracts/token/ERC721/ERC721.sol gibi standart sözleşmeleri doğrudan kullanabilirsiniz. Bu şekilde, bir yandan NFT ile pozisyonları yönetebilirken, diğer yandan mevcut standart sözleşmeleri kullanarak geliştirme verimliliğini artırabilirsiniz.
Özet
Kendi deneyiminizle basit bir merkeziyetsiz borsa geliştirmek, DEX'in kod uygulamasını daha derinlemesine anlamanızı sağlar ve gerçek projelerde daha fazla bilgi edinmenizi sağlar. Web3 veya DeFi projeleri geliştirme ile ilgileniyorsanız, pratik deneyim size büyük fayda sağlayacaktır.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
7 Büyük Sözleşme Geliştirme İpuçları: DEX Kodlarından Merkezi Olmayan Finans En İyi Uygulamalarını Öğrenmek
Sözleşme Geliştirmenin Harika İpuçları: Uniswap Kodundan Öğrenilen Deneyimler
Son zamanlarda merkeziyetsiz borsa geliştirme kılavuzunu yazarken, tanınmış bir DEX'in kod uygulamasını referans aldım ve birçok yeni bilgi edindim. Daha önce basit bir NFT sözleşmesi geliştirmiş bir geliştirici olarak, bu benim Defi sözleşmesi geliştirme konusundaki ilk denemem. Bu küçük ipuçlarının sözleşme geliştirmeyi öğrenmek isteyen yeni başlayanlar için çok faydalı olacağına inanıyorum.
Şimdi bu ilginç ipuçlarına birlikte bakalım, bazıları hatta tuhaf beceriler olarak adlandırılabilir.
Tahmin Edilebilir Sözleşme Dağıtım Adresi
Genellikle bir sözleşme dağıtıldığında, nonce ile ilişkili olduğu için görünüşte rastgele bir adres elde edilir, bu nedenle sözleşme adresini tahmin etmek zordur. Ancak belirli senaryolar altında, işlem çiftleri ve ilgili bilgiler aracılığıyla sözleşme adresini çıkarmamız gerekebilir. Bu, birçok durumda çok kullanışlıdır, örneğin işlem yetkilerini değerlendirmek veya likidite havuzu adresini almak gibi.
CREATE2 yöntemi ile sözleşme oluşturmak için salt parametresi ekleyerek sözleşme oluşturabilirsiniz, böylece oluşturulan sözleşme adresi tahmin edilebilir. Adres oluşturma mantığı şudur: Yeni adres = hash("0xFF", oluşturucu adresi, salt, initcode).
Geri çağırma fonksiyonlarını iyi kullanma
Solidity'de, sözleşmeler birbirlerini çağırabilir. Bir senaryo, A'nın bir metodunda B'yi çağırmasıdır, B çağrıldığı metodun içinde A'ya geri çağrıda bulunur, bu bazı senaryolarda oldukça kullanışlıdır.
Örneğin, bir DEX sözleşmesinin swap yöntemini çağırdığınızda, swapCallback geri çağrılır ve bu işlem için hesaplanan gerçek Token iletilir. Çağıran taraf, geri çağırma sırasında gereken Token'ı DEX sözleşmesine transfer etmelidir, swap yöntemini iki parçaya ayırıp çağıran tarafın çağırmasını sağlamamalıdır. Bu, swap yönteminin güvenliğini garanti eder, tüm mantığın eksiksiz bir şekilde yürütülmesini sağlar ve güvenliği sağlamak için karmaşık değişken kayıtlarına gerek kalmaz.
İstisna ile bilgi iletimi, işlem tahmini için try catch kullanımı
Bazı DEX'in kodunda, swap metodunun try catch ile sarmalanarak çalıştırıldığını gördük. Bunun sebebi nedir? Çünkü swap metodunu simüle ederek işlem için gerekli Token'ı tahmin etmemiz gerekiyor, ancak tahmin sırasında gerçekten Token değişimi gerçekleşmeyeceğinden hata veriyor. İşlem geri çağırma fonksiyonu içinde özel bir hata fırlatarak, bu hatayı yakalıyor ve hata mesajından gerekli bilgileri ayrıştırıyor.
Bu biraz hileli görünüyor ama çok pratiktir. Bu sayede tahmin edilen ticaret talebini karşılamak için takas yöntemini değiştirmeye gerek kalmıyor, mantık da daha basit.
Büyük Sayılar ile Hassasiyet Problemini Çözmek
DEX kodunda birçok hesaplama mantığı vardır, örneğin mevcut fiyat ve likiditeye göre takas edilen Token'ı hesaplamak. Bu süreçte, bölme işlemi sırasında hassasiyet kaybını önlememiz gerekiyor. Bazı uygulamalarda, hesaplama süreci sık sık "<< FixedPoint96.RESOLUTION" işlemini kullanır; bu, 96 bit sola kaydırmayı temsil eder ve 2^96 ile çarpmaya eşdeğerdir. Sola kaydırdıktan sonra bölme işlemi yaparak, normal işlemlerde taşma olmadan ( genellikle uint256 ile hesaplanır, bu sayede ) durumunda hassasiyet garanti edilir.
Share Yöntemi ile Kazancı Hesaplama
DEX'te, LP( likidite sağlayıcısı )'in işlem ücretlerini kaydetmemiz gerekiyor. Açıkça, her işlemde her LP'nin kendi işlem ücretini kaydetmek mümkün değil, bu çok fazla Gas tüketir. Peki, bu durumda ne yapmalıyız?
Position içinde feeGrowthInside0LastX128 ve feeGrowthInside1LastX128 içeren bir yapı tanımlanabilir; bunlar, her pozisyonda son komisyon çekiminde her likiditenin alması gereken komisyonu kaydeder.
Kısaca, toplam işlem ücretini ve her bir likiditenin alması gereken işlem ücretini kaydetmek yeterlidir. LP, işlem ücretini çekerken, sahip olduğu likiditeye göre çekebileceği işlem ücretini hesaplayabilir. Bu, bir şirketin hisse senedine sahip olmaya benzer; hisse senedi gelirini çekerken yalnızca şirketin tarihi hisse başına kazancını ve en son çektiğinizdeki kazancı bilmeniz yeterlidir.
Tüm bilgilerin zincir üzerinden alınması gerekmez
Blok zincirinde depolama görece pahalıdır, bu nedenle tüm bilgilerin zincire alınması veya zincirden alınması gerekmez. Örneğin, bazı DEX ön yüz web sitelerinin çağırdığı birçok arayüz, geleneksel Web2 arayüzleridir.
Ticaret havuzları listesi, ticaret havuzu bilgileri vb. normal bir veritabanında saklanabilir, bazıları zincirden düzenli olarak senkronize edilmesi gerekebilir, ancak ilgili verileri almak için zincir veya düğüm hizmetleri tarafından sağlanan RPC arayüzünü gerçek zamanlı olarak çağırmak gerekmez.
Elbette, ana işlemler kesinlikle zincir üzerinde gerçekleştirilecektir.
Sözleşme bölmeyi öğrenin, mevcut standart sözleşmeleri kullanın
Bir proje birden fazla gerçek dağıtılmış sözleşme içerebilir. Gerçek dağıtımda yalnızca bir sözleşme olsa bile, sözleşmeyi miras alma yöntemiyle birden fazla sözleşmeye ayırarak bakımını yapabiliriz.
Ayrıca, @openzeppelin/contracts/token/ERC721/ERC721.sol gibi standart sözleşmeleri doğrudan kullanabilirsiniz. Bu şekilde, bir yandan NFT ile pozisyonları yönetebilirken, diğer yandan mevcut standart sözleşmeleri kullanarak geliştirme verimliliğini artırabilirsiniz.
Özet
Kendi deneyiminizle basit bir merkeziyetsiz borsa geliştirmek, DEX'in kod uygulamasını daha derinlemesine anlamanızı sağlar ve gerçek projelerde daha fazla bilgi edinmenizi sağlar. Web3 veya DeFi projeleri geliştirme ile ilgileniyorsanız, pratik deneyim size büyük fayda sağlayacaktır.