Yükseltilebilir Akıllı Sözleşmeler
Bir ev veya daire kiralamak için bir kontrat imzalamak üzeresiniz. Ev sahibi: “Bu sadece standart bir kira sözleşmesi. Kelimenin tam anlamıyla bir tanesini Google’da arattık ve kopyaladık. Kendim eklediğim son madde dışında , hepsi sadece standart bir kalıp”. Yine de, sözleşmeyi dikkatlice ve iyice okumak için zaman ayırın. Tabii ki, hepsi çok standart ve şaşırtıcı değil. Evcil hayvanlara izin verilir, bu harika çünkü kedinizden ayrılamazsınız.
Sonra en son satırı okursunuz: “Bu sözleşmenin tüm içeriği, mülk sahibi tarafından herhangi bir zamanda, herhangi bir nedenle, önceden haber vermeksizin veya kiracının rızası olmadan değiştirilebilir veya tamamen değiştirilebilir.” Bu doğru görünmüyor. Tekrar okudun. “Yani bu, isterseniz tüm sözleşmeyi ‘Herhangi bir mobilyada veya boyada herhangi bir çizik bulunursa, orijinalinde orada olup olmadığına bakılmaksızın, kiracının sahibine 10 kez borçlu olduğu anlamına mı geliyor? mülkün piyasa değeri’?” Ev sahibi cevap verir: “Evet, teknik olarak evet, sanırım yapabilirim, evet. Ama bunu yapmazdım!”
EVM uyumlu blok zincirlerdeki yükseltilebilir akıllı sözleşmelerden bahsedelim.
Sorun
Akıllı sözleşme geliştirmenin en çarpıcı özelliklerinden biri, sözleşme dağıtıldıktan sonra hiçbir şeyi değiştirememesidir. Dağıtılan bir web uygulamasını düşünün: Dağıtımdan sonra keşfedilen bir hata utanç verici veya zararlı olabilir, ancak daha fazla zarar vermeden hemen düzeltilebilir. Dağıtılmış bir masaüstü veya mobil uygulamada durum biraz daha kötüdür: kullanıcıların kasıtlı olarak yeni bir sabit sürümü indirmesi ve yüklemesi gerekebilir. Ancak akıllı sözleşme sonsuza kadar blok zincirindedir, değişmez. Bu bir özelliktir; kullanıcılar sözleşmenin değişmezliğine güvenebilirler. Sözleşmenin kullanımını ve güvenliğini değerlendirmişlerse ve onunla rahat hissederlerse, her zaman böyle olacağına güvenebilirler.
Bir tür acil durum çıkarma düğmesi olarak EVM, blok zincirindeki sözleşmeyi devre dışı bırakacak ve aynı zamanda tüm fonları geri çekecek SELFDESTRUCT işlem kodunu sağladı. Değişmezliği bozduğu söylendiği için SELFDESTRUCT kullanımı tartışmalı olmuştur. Ayrıca halı çekme için bariz etkileri vardır.
Ardından, onu bir adım daha ileri götüren yükseltilebilirlik geldi.
Yükseltilebilirlik hakkında bazı teknik açıklamalar: Bir sözleşmeyi yükseltilebilir hale getirmenin birden fazla yolu vardır. Farklı özelliklere, avantajlara ve dezavantajlara sahip birçok tasarım modeli vardır.
En popüler olanı UUPS – Evrensel Yükseltilebilir Proxy Standardı gibi görünüyor. Pek çok yükseltilebilirlik modeli gibi, EVM bayt kodu belirtiminin iki özelliğini akıllıca kullanır: geri dönüş işlevleri (belirtilen işlev seçici bulunamadığında bir sözleşmede yürütülen bir işlev) ve DELEGATECALL (bir işlevi çağıran tartışmalı olarak tehlikeli bir talimat) başka bir akıllı sözleşme, aranan sözleşmeye arama sözleşmesinin depolanmış verilerine tam erişim sağlarken).
Bu modelde, müşterilerin etkileşimde bulunduğu sözleşme yalnızca bir vekildir, perde arkasında kullanılan mantığı tanımlayan gerçek sözleşme, herhangi bir zamanda farklı bir mantıkla farklı bir sözleşme için değiştirilebilir. Bu, kiracının bilgisi veya rızası olmadan tamamen değişen kira sözleşmesine benzer. Sözleşme yükseltildiğinde, müşteri hala aynı sözleşme (vekil) adresiyle etkileşim halindedir; yeni sözleşmeye geçmek için bilinçli bir seçim yapmıyorlar.
Güvenlik için standart uygulama, akıllı bir sözleşmeyi kullanmaya başlamadan önce kapsamlı bir şekilde denetlemektir. Bu iyi bir uygulamadır ve mantıklıdır. Bu, yasal bir sözleşmeyi imzalamadan önce yukarıdan aşağıya tamamen okumaya benzer. Sözleşmenin yeni bir versiyonu (yeni bir adreste) yayınlanırsa, bilinçli ve kasıtlı olarak yeni sözleşmeye geçmeden önce bu süreç makul bir şekilde yeni sözleşme için tekrarlanır. Bununla birlikte, daha önce açıklanan kurnazlıklara karşı korunmak için, sözleşmeye yapılan her çağrıdan önce bu işlemin tekrarlanması gerekecek ve herhangi bir süre içinde jetonları veya para birimini saklaması tavsiye edilmeyecek . Büyük bir fark.
Uygun Bir Kullanım Örneği
Yükseltilebilir modellerin, akıllı sözleşmelerin geliştiricileri ve sürdürücüleri için büyük faydaları vardır. Ne büyük bir rahatlama! Her şeyi baştan sona test ettik, kontrol ettik ve yeniden kontrol ettik, ancak bir şeyler ters giderse bir çıkışımızın olduğunu bilmenin rahatlığını yaşayabiliriz . Ancak akıllı sözleşme kullanıcıları için? Çok değil. Şahsen böyle bir sözleşmeye yalnızca aşağıdaki koşullardan biri veya birkaçı altında güvenirim:
- Sözleşme sahibi şahsen tanıdığım ve çok güvendiğim biriydi ve çok fazla değeri risk altında değil
- Sözleşmenin kullanımı bir geçiştir; param veya jetonlarım sadece bir işlem alanı için sözleşmenin kontrolünde olacak ve daha sonra başka bir yerde olacak; ve çok fazla değer risk altında değil
- Hiçbir değer risk altında değildir; sözleşme işlevsel bir şey yapıyor ama fonları idare etmiyor (yani bana zarar veremez)
- Sözleşme, yükseltilmek için benim oyumu gerektiriyor.
Sonuncusuna bakalım, çünkü bu bence blockchain kodunda yükseltilebilirlik için çok geçerli bir kullanım durumu. İşte örnek bir senaryo:
Çocuklarının eğitimi için istenmeyen seçenekler olarak gördüklerinden bıkan bir grup ebeveyn, çocukları için bir evde eğitim kooperatifi oluşturmak üzere bir araya gelmeye karar verdi. Bazı öğretmenleri işe alıyorlar, bir yer kiralıyorlar ve eğitim ekipmanı satın alıyorlar, tüm fonlarını bir araya getiriyorlar ve tüm masrafları bölüşüyorlar. Tüm ebeveynler kriptodaki her şey için ödeme yapmıyordu, ancak yine de teklif vermek ve oy vermek için akıllı bir sözleşmenin faydalı olduğu düşünülüyordu.
Akıllı sözleşme tarafından uygulanan ve blok zinciri tarafından şeffaf ve aldatılamaz hale getirilen bu sistemde, sözleşmedeki herhangi bir katılımcı bir teklif sunabilir, Örneğin, “Bence Ayşe Öğretmeni Beden Eğitimi eğitmeni olarak işe almalıyız” veya “öğretmenlerin maaşları %10 arttırmalıyız.” Önerilerin kabul edilmesi için belirli bir evet/hayır oyu oranı gerekiyor.
Oylamaya yalnızca kayıtlı katılımcılar (sözleşmede kayıtlı adresleri) katılabilir. Dolayısıyla bu sözleşme, genel blok zincirinde herkese açıktır, ancak özel, geçerli ve normal bir kullanım durumu olan kullanımdır (kapalı bir kullanıcı grubu). Zaman sınırları, teklif türleri vb. gibi başka kurallar ve ayrıntılar da olabilir, pekala hayal edebilirsiniz. Sözleşmeyi kullanılamaz hale getirebilecek mantık hatalarının neden olduğu kurnazlıkları önlemek için sözleşme yükseltilebilir hale getirildi. Ancak uyarı, tüm sözleşme katılımcılarının önerilen bir yükseltmeyi onaylamak için oy kullanması gerektiğiydi.
Yükseltme için oylama mantığı, normal teklifler için oylama mantığından ayrıdır. Şu şekilde çalışır: bir sözleşme adresi (herhangi bir katılımcı tarafından) yükseltme için aday olarak sunulur. Her katılımcı yeni sözleşmeyi gözden geçirmek için zaman bulduktan sonra, her biri, oyladıkları sözleşmenin gerçekten önerilen sözleşme olduğundan emin olmak için oylarında sözleşme adresini belirterek önerilen sözleşme için evet veya hayır oyu verebilir. Tüm oylar sayıldıktan sonra, yükseltme için karar “evet” ise, aday için uygulama devre dışı bırakılacaktır. Aday adresi temizlendi.
contract SchoolCoopVoting is UUPSUpgradeable {
address public proposedUpgrade = address(0);
address[] public participants;
mapping(address => bool) private participantsMapping;
mapping(address => bool) private proposedUpgradeVotes;
modifier participantOnly {
require(isParticipant(msg.sender), "Only registered participants may perform this action");
_;
}
function voteForUpgrade(address upgradeAddr, bool yeaOrNay) external participantOnly {
require(upgradeAddr == proposedUpgrade, "You are voting for the wrong proposed upgrade");
proposedUpgradeVotes(upgradeAddr)(msg.sender) = yeaOrNay;
}
function upgradeTo(address upgradeAddr) external participantOnly {
_doUpgrade(upgradeAddr);
}
function upgradeToAndCall(address newImplementation, bytes memory data) external payable override onlyProxy {
super.upgradeToAndCall(newImplementation, data);
afterUpgrade(newImplementation);
}
function isParticipant(address addr) public returns (bool) {
return participantsMapping(addr);
}
function upgradeTo(address newImplementation) external override onlyProxy {
super.upgradeTo(newImplementation);
afterUpgrade(newImplementation);
}
function _authorizeUpgrade(bool newImplementation) internal override participantOnly {
require(newImplementation == proposedUpgrade, "Sir, this is a Wendy's");
for(uint256 n=0; n<participants.length(); n++) {
if (!proposedUpgradeVotes(participants[n])) {
revert("The upgrade in question has not been approved");
}
}
}
function afterUpgrade(address /*newImplementation*/) internal {
proposedUpgrade = address(0);
clearMapping();
}
function clearMapping() internal {
for(uint256 n=0; n<participants.length(); n++) {
proposedUpgradeVotes(participants[n]) = false;
}
}
}Tüm katılımcılar yeni uygulamayı kabul ederse, yeni bir uygulamaya geçmek adil olur . Bu, yalnızca katılımcı sayısının yönetilebilir derecede küçük olduğu durumlarda pratik olacaktır.
Sonuç Bağlamı
Bir şeyi yapabiliyor olmamız, yapmamız gerektiği anlamına gelmez . Yükseltilebilirlik, geliştiriciler için büyük bir nimettir, ancak akıllı (hatta aptal) sözleşmelerin tüm önermesinin ardındaki çok temel bir şeyi bozar: değişmezlik. İronik olarak, bazılarını verseler bile Yükseltilebilir akıllı sözleşmeler için uygun kullanım durumları düşündüğünüzden daha dar olabilir. Güvenlik alanında güvence, farklı türde bir güvenlik endişesi açabilirler. Bariz faydalarına rağmen – bence – akıllı sözleşmelerde yükseltilebilirlik için dar kullanım durumları var.
Bu makaleyi okuduğunuz için teşekkürler! Bana destek olmak isterseniz;
Beni Twitter, Linkedin ve YouTube‘da takip edin.
Kısa bir yorum bırakmayı UNUTMAYIN!
