Sözleşme Geliştirme Küçük İpuçları Paylaşımı: Uniswap'tan Öğrenilen Deneyimler
Son zamanlarda merkeziyetsiz borsa projeleri geliştirirken, tanınmış bir DEX'in kod uygulamasını referans aldım ve birçok faydalı bilgi edindim. Defi akıllı sözleşme geliştirmeye yeni başlayan biri olarak, bu teknikler benim için ilham verici oldu ve akıllı sözleşme geliştirmek isteyen diğer arkadaşlara da yardımcı olacağına inanıyorum.
Tahmin Edilebilir Sözleşme Adresi
Genellikle dağıtılan sözleşmelerin elde edilen adresleri nonce ile ilgili olduğu için rastgele gibi görünür. Ancak bazı durumlarda, işlem bilgilerinden sözleşme adresini çıkarmamız gerekir, örneğin işlem yetkisini belirlemek veya likidite havuzunun adresini almak.
Bu, sözleşmeyi CREATE2 yöntemiyle oluşturmak suretiyle gerçekleştirilebilir. Belirli yöntem, sözleşme oluşturulurken salt parametresinin eklenmesidir:
katılık
pool = address(new UniswapV3Pool{salt: keccak256(abi.encode(token0, token1, fee))}());
Bu şekilde oluşturulan kontrat adresi tahmin edilebilir, aşağıdaki mantığı takip eder:
Yeni adres = hash("0xFF", oluşturucu adres, tuz, initcode)
Geri çağırma fonksiyonlarının makul kullanımı
Bazı senaryolarda, sözleşmeler arasındaki karşılıklı çağrılar yararlıdır. Örneğin, A yöntemi B'yi çağırır, B çağrılan yöntemde A'yı geri arar.
Bir DEX'te, swap yöntemini çağırarak işlem yapıldığında, swapCallback'i geri çağırır ve hesaplanan bu işlem için gerçekten gereken Token'i geçirir. Çağıran taraf, geri çağırma sırasında gerekli Token'i işlem havuzuna aktarmalıdır ve swap yöntemini parçalara ayırmamalıdır. Bu, swap yönteminin tam olarak yürütülmesini garanti eder ve güvenliği sağlamak için karmaşık değişken kayıtları gerektirmez.
Anormal Durumda Bilgi Aktarmak
Tahmini işlem yaparken, swap yöntemini simüle etmemiz gerekiyor, ancak Token'ları gerçekten değiştirmeyeceğiz, bu yüzden hata verecek. Bir DEX, işlem geri çağırma fonksiyonunda özel bir hata fırlatarak ve ardından bu hatayı yakalayıp gerekli bilgileri çıkararak tahmin işlemini gerçekleştirir.
Bu yöntem, kolayca görünse de oldukça pratiktir. Tahmini talep için swap yöntemini değiştirmeye gerek yoktur, mantık daha basittir.
Büyük Sayılar Kullanarak Hassasiyet Sorununu Çözme
Hesaplama ile ilgili kodlarda, bölme işlemi sırasında hassasiyet kaybını önlemek gerekir. Bazı DEX'ler sıkça "<< FixedPoint96.RESOLUTION" işlemini kullanır, bu da 2^96 ile çarpmaya eşdeğerdir. Soldan kaydırdıktan sonra bölme işlemi yapılması, taşma olmadan hassasiyetin korunmasını sağlar.
Teorik olarak hâlâ bir hassasiyet kaybı olabilir, ancak genellikle sadece en küçük birim kaybıdır, kabul edilebilir.
Paylaşım Yöntemi ile Kazanç Hesaplama
Likidite sağlayıcı (LP) için işlem ücretleri hesaplaması, her işlemde kaydedilemez, bu büyük miktarda Gas tüketir. Bazı DEX'ler toplam işlem ücretini ve her likiditenin alacağı işlem ücretini kaydetme yöntemini kullanmaktadır.
LP çekim ücreti alırken, sahip olunan likiditeye göre çekilebilecek miktar hesaplanır. Şirket hisselerine sahip olma durumuna benzer, kazanç çekilirken her hisse senedinin tarihsel kazancı ve son çekim zamanındaki kazanç bilinmesi yeterlidir.
Bilgi Edinme Yöntemlerini Akıllıca Seçmek
Blok zincirinde depolama görece pahalıdır, bu yüzden tüm bilgilerin blok zincirine alınması veya blok zincirinden alınması gerekmez. Örneğin, işlem havuz listeleri ve bilgiler gibi veriler sıradan bir veritabanında depolanabilir ve düzenli olarak blok zincirinden senkronize edilebilir.
Bazı blok zinciri RPC sağlayıcıları, verileri daha hızlı almak için gelişmiş arayüzler sunar. Ancak, önemli işlemler yine de zincir üzerinde gerçekleştirilmelidir.
Sözleşme Bölme ve Standart Sözleşme Yeniden Kullanımı
Bir proje birden fazla sözleşme içerebilir, hatta tek bir sözleşme gerçek olarak dağıtıldığında bile miras alma ile birden fazla sözleşmeye bölünebilir.
Bir DEX'in NFT konum yönetim sözleşmesi birden fazla sözleşmeden miras almıştır:
Aynı zamanda, OpenZeppelin'in ERC721 standart sözleşmesini kullanarak hem pozisyon yönetimini kolaylaştırmakta hem de geliştirme verimliliğini artırmaktadır.
Özeti
Basit bir merkeziyetsiz borsa geliştirmek, olgun projelerin kod implementasyonunu daha derinlemesine anlamanıza ve daha fazla pratik bilgi edinmenize yardımcı olacaktır. Umarım bu küçük ipuçları size ilham verir, iyi geliştirmeler!
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.
Ana akım DEX sözleşme geliştirme ile ilgili 7 pratik ipucu
Sözleşme Geliştirme Küçük İpuçları Paylaşımı: Uniswap'tan Öğrenilen Deneyimler
Son zamanlarda merkeziyetsiz borsa projeleri geliştirirken, tanınmış bir DEX'in kod uygulamasını referans aldım ve birçok faydalı bilgi edindim. Defi akıllı sözleşme geliştirmeye yeni başlayan biri olarak, bu teknikler benim için ilham verici oldu ve akıllı sözleşme geliştirmek isteyen diğer arkadaşlara da yardımcı olacağına inanıyorum.
Tahmin Edilebilir Sözleşme Adresi
Genellikle dağıtılan sözleşmelerin elde edilen adresleri nonce ile ilgili olduğu için rastgele gibi görünür. Ancak bazı durumlarda, işlem bilgilerinden sözleşme adresini çıkarmamız gerekir, örneğin işlem yetkisini belirlemek veya likidite havuzunun adresini almak.
Bu, sözleşmeyi CREATE2 yöntemiyle oluşturmak suretiyle gerçekleştirilebilir. Belirli yöntem, sözleşme oluşturulurken salt parametresinin eklenmesidir:
katılık pool = address(new UniswapV3Pool{salt: keccak256(abi.encode(token0, token1, fee))}());
Bu şekilde oluşturulan kontrat adresi tahmin edilebilir, aşağıdaki mantığı takip eder:
Yeni adres = hash("0xFF", oluşturucu adres, tuz, initcode)
Geri çağırma fonksiyonlarının makul kullanımı
Bazı senaryolarda, sözleşmeler arasındaki karşılıklı çağrılar yararlıdır. Örneğin, A yöntemi B'yi çağırır, B çağrılan yöntemde A'yı geri arar.
Bir DEX'te, swap yöntemini çağırarak işlem yapıldığında, swapCallback'i geri çağırır ve hesaplanan bu işlem için gerçekten gereken Token'i geçirir. Çağıran taraf, geri çağırma sırasında gerekli Token'i işlem havuzuna aktarmalıdır ve swap yöntemini parçalara ayırmamalıdır. Bu, swap yönteminin tam olarak yürütülmesini garanti eder ve güvenliği sağlamak için karmaşık değişken kayıtları gerektirmez.
Anormal Durumda Bilgi Aktarmak
Tahmini işlem yaparken, swap yöntemini simüle etmemiz gerekiyor, ancak Token'ları gerçekten değiştirmeyeceğiz, bu yüzden hata verecek. Bir DEX, işlem geri çağırma fonksiyonunda özel bir hata fırlatarak ve ardından bu hatayı yakalayıp gerekli bilgileri çıkararak tahmin işlemini gerçekleştirir.
Bu yöntem, kolayca görünse de oldukça pratiktir. Tahmini talep için swap yöntemini değiştirmeye gerek yoktur, mantık daha basittir.
Büyük Sayılar Kullanarak Hassasiyet Sorununu Çözme
Hesaplama ile ilgili kodlarda, bölme işlemi sırasında hassasiyet kaybını önlemek gerekir. Bazı DEX'ler sıkça "<< FixedPoint96.RESOLUTION" işlemini kullanır, bu da 2^96 ile çarpmaya eşdeğerdir. Soldan kaydırdıktan sonra bölme işlemi yapılması, taşma olmadan hassasiyetin korunmasını sağlar.
katı uint256 numerator1 = uint256(likidite) << FixedPoint96.RESOLUTION; uint256 numerator2 = sqrtRatioBX96 - sqrtRatioAX96; amount0 = numerator1 * numerator2 / (sqrtRatioBX96 * sqrtRatioAX96);
Teorik olarak hâlâ bir hassasiyet kaybı olabilir, ancak genellikle sadece en küçük birim kaybıdır, kabul edilebilir.
Paylaşım Yöntemi ile Kazanç Hesaplama
Likidite sağlayıcı (LP) için işlem ücretleri hesaplaması, her işlemde kaydedilemez, bu büyük miktarda Gas tüketir. Bazı DEX'ler toplam işlem ücretini ve her likiditenin alacağı işlem ücretini kaydetme yöntemini kullanmaktadır.
LP çekim ücreti alırken, sahip olunan likiditeye göre çekilebilecek miktar hesaplanır. Şirket hisselerine sahip olma durumuna benzer, kazanç çekilirken her hisse senedinin tarihsel kazancı ve son çekim zamanındaki kazanç bilinmesi yeterlidir.
Bilgi Edinme Yöntemlerini Akıllıca Seçmek
Blok zincirinde depolama görece pahalıdır, bu yüzden tüm bilgilerin blok zincirine alınması veya blok zincirinden alınması gerekmez. Örneğin, işlem havuz listeleri ve bilgiler gibi veriler sıradan bir veritabanında depolanabilir ve düzenli olarak blok zincirinden senkronize edilebilir.
Bazı blok zinciri RPC sağlayıcıları, verileri daha hızlı almak için gelişmiş arayüzler sunar. Ancak, önemli işlemler yine de zincir üzerinde gerçekleştirilmelidir.
Sözleşme Bölme ve Standart Sözleşme Yeniden Kullanımı
Bir proje birden fazla sözleşme içerebilir, hatta tek bir sözleşme gerçek olarak dağıtıldığında bile miras alma ile birden fazla sözleşmeye bölünebilir.
Bir DEX'in NFT konum yönetim sözleşmesi birden fazla sözleşmeden miras almıştır:
katılık sözleşme NonfungiblePositionManager'dır INonfungiblePositionManager, Multicall, PeripheryImmutableState, HavuzBaşlatıcı, Likidite Yönetimi, PeripheryValidation, SelfPermit, ERC721İzin {...}
Aynı zamanda, OpenZeppelin'in ERC721 standart sözleşmesini kullanarak hem pozisyon yönetimini kolaylaştırmakta hem de geliştirme verimliliğini artırmaktadır.
Özeti
Basit bir merkeziyetsiz borsa geliştirmek, olgun projelerin kod implementasyonunu daha derinlemesine anlamanıza ve daha fazla pratik bilgi edinmenize yardımcı olacaktır. Umarım bu küçük ipuçları size ilham verir, iyi geliştirmeler!