Genel Zincirlerde Erişim Kontrolleri

Blok zincirleri izole edilmiştir. Devlet, dünyanın geri kalanı tarafından kolay erişimden korunan, fildişi bir kulenin tepesinde, duvarlarla çevrili bir bahçede yaşıyor. Etki alanı içinde, zincirin yürütme ortamı, akıllı sözleşmelerin yürütülmesini, hesaplar arasında para ve jetonların taşınmasını ve devlet deposunun güncellenmesini yönetir. Bahçenin kapıları, genel anahtar kimlik doğrulaması tarafından kontrol edilir: bir hesabın özel anahtarıyla bir dizi imzalamak, o hesaptan bir işlem başlatmanıza izin verir. İletiler, işlemin yetkili bir imzalayıcıdan kaynaklandığı belirlendikten sonra bir hesaptan gönderilir. Yürütme başladığında, ortam, akıllı sözleşmeler arasında mesaj geçişini yönetir ve yürütmenin sonunda durmasını sağlar.

Kimlik Doğrulama ve Yetkilendirme

Ne yazık ki, kriptografi çok anlamlı değil. Kimlik doğrulamayı işleyebilir, ancak ayrıntılı yetkilendirme için pek çok araç sağlamaz. Ethereum’da, çok sayıda araştırma ve tartışma, harici olarak sahip olunan hesaplara (EOA) erişimin daha karmaşık yetkilendirilmesine girdi. “ Hesap soyutlama ”, kullanıcıların hesaplarına erişimi kontrol eden keyfi programlar ayarlamasına izin vermeyi amaçlar, böylece hareket belirli kurallara uyduğu sürece hesaptaki jetonlar herkes tarafından taşınabilir. EIP-3074 gibi daha yeni tasarımlar , çok daha düşük karmaşıklık maliyetiyle hesap soyutlamanın birçok avantajını sağlar.

Erişim Kontrol Listesi

Blok zinciri kaynaklarına erişimi kontrol etmeye yönelik araçlar genellikle zincirin etki alanı ile dünyanın geri kalanı arasındaki sınırda standart hale getirilir. En karmaşık haliyle, mevcut yetkilendirme şemaları mütevazi Erişim Kontrol Listesi’nden (ACL) oluşur — bir kaynağa erişim (ör: bir ERC-20 Akıllı Sözleşmesindeki nane işlevi), dışarıdan bakan belirli hesaplara bağlanır. Ancak, bir zincirin etki alanındaki mesajların da kimlik doğrulaması ve güçlü yetkilendirmeye ihtiyacı vardır.

En basit Ethereum akıllı sözleşmeleri bile aynı gerilimi paylaşır: yeteneklerine erişim, adres listeleri tarafından kontrol edilir. Token sözleşmeleri, sahibine bir bakiye üzerinde kontrol sağlar. Merkezi olmayan değişim (DEX) sözleşmelerinin, değer vermeden önce değer aldıklarından emin olmaları gerekir. Ethereum Sanal Makinesi (EVM) dahili kimlik doğrulamayı yönetirken (her mesaj `msg.sender` alanında gönderenin adresini içerir), yetkilendirmeyi kontrol etmek için standart bir modeli yoktur. Her akıllı sözleşme geliştiricisinin, belirli şeylerdeki izinleri izlemek için ısmarlama bir erişim listesi sistemi oluşturması gerekir. Yanlış uygulanan kimlik doğrulama sistemleri, bir dizi karmaşık DeFi hatalarının kökenindedir ve milyonlarca dolarlık zarara neden olmuştur.

Ölümcül kusur, özünde ACL’ler ile oluşturulmuş herhangi bir sistem tarafından paylaşılır. Harika blog gönderisini alıntılamak için “Yetenekler Nelerdir?” Chip Morningstar tarafından:

Bir uygulamayı çalıştırdığınızda, işletim sistemi söz konusu olduğunda, uygulamanın yaptığı her şey sizin tarafınızdan yapılır. Bunu ifade etmenin bir başka yolu da, çalıştırdığınız bir uygulama yapabileceğiniz her şeyi yapabilir.

Bu sorunlar, İşletim Sistemlerinin gençliğinden beri var ve blok zincirleri onları devraldı, çünkü ACL’ler bir sistemdeki erişimi anlamanın iyi belgelenmiş, yerleşik ve nispeten sezgisel bir yolu. Bununla birlikte, daha yeni blok zincirler, bu tasarım seçimini, genel olarak “Nesne Yetenekleri” (OCAP) olarak bilinen (nispeten) daha yeni bir izin modeli lehine yeniden düşünüyor.

OCAP’ler, ERTP ve Zoe

Agoric Blockchain, Elektronik Haklar Transfer Protokolünün (ERTP) (Agoric’in dijital varlıklar için belirteç standardı ) merkezinde OCAP’lere sahiptir . ERC-20 ve ERC-721'e benzer şekilde ERTP, dijital varlıklar oluşturmak için bir API uygulayan bir standarttır. ERC-20 ve ERC-721'den farklı olarak, ERTP tanıdık bir dilde, JavaScript’te yazılmıştır ve daha ayrıntılı yetkilendirmeye izin vermek için JavaScript’in bazı dil özelliklerinden yararlanır. ERTP , bir adres listesi içeren bir sözleşme yerine, erişim kontrolünü uygulamak için OCAP’leri kullanır ve temel bir kurala göre çalışır:

“Programınızın bir nesneye referansı varsa, o nesne üzerindeki yöntemleri çağırabilir. Referansı yoksa olamaz.”

Başka bir deyişle, asıl nesneye erişiminiz yoksa onu kullanamazsınız. Basitçe bir değişkenin veya genel sınıfın adını bilmek size bir nesneye referans vermez. Onu ancak 1) yaratırsanız, 2) inşa ederseniz veya 3) onunla tanıştırırsanız elde edebilirsiniz.

JavaScript’e aşinaysanız, bu referansla erişim fikri, kapatma kavramıyla açıklanabilir . “Bir kapatma, çevreleyen durumuna (sözcüksel ortam) referanslarla birlikte paketlenmiş (kapalı) bir işlevin birleşimidir.” [ MDN ]

Bir işlev yürütüldükten sonra bile, dış kapsamına bir başvuru içerebilir. Kapanışları kullanarak geliştiriciler, yalnızca nesneye bir referansınız varsa erişilebilen özel yöntemler ve veriler oluşturabilir. Bu, dışarıdaki tarafların görebilseler bile ona erişemeyecekleri anlamına gelir. Bu referans yoluyla yetkilendirme kavramı, güvenli sözleşmeler yazmayı çok daha kolay hale getirir. (Buradaki bir uyarı, JavaScript’teki bazı dil özellikleri akıllı sözleşmeler yazmayı daha az güvenli hale getirdiğinden, ERTP kullanan akıllı sözleşmelerin JavaScript’in güvenli bir alt kümesinde yürütülmesi gerektiğidir).

Geliştiricilerin OCAP’leri ve ERTP’yi kullanarak akıllı sözleşmeler yazmasına yardımcı olmak için Agoric, Zoe olarak bilinen bir akıllı sözleşme çerçevesi de geliştirdi . Zoe sözleşmeleri, JavaScript’in güvenli bir alt kümesinde yazılır ve tüm kullanıcı dijital varlıklarını otomatik olarak emanet eder ve sonraki ödemelerini yönetir. Bu, hatalı bir sözleşmenin bile kullanıcıların varlıklarını kaybetmesine neden olmayacağı anlamına gelir.

Karmaşıklık genellikle kasıtsız ve maliyetli hatalara yol açabilir. Akıllı sözleşmeleri on yıllardır bilinen bir dilde yazabilme yeteneği, bu hataların sayısını azaltmaya yardımcı olabilir. Agoric, JavaScript’in OCAP yeteneklerinden yararlanarak geliştiricilere daha ayrıntılı yetkilendirme sağlayabilir ve duvarlı bahçelerde erişimin çözülmesine yardımcı olur.