Giriş
Akıllı sözleşmeler, blok zinciri ağına yerleştirildikten sonra kalıcı ve değiştirilemez olacak şekilde programlanmıştır. Bu değişmezlik, güvenlik ve güven kaynağıdır, ancak geliştiricilerin hataları düzeltmesi veya yeni özellikler eklemesi gerektiğinde zorluklar da yaratır.
Değişiklik yapılması gerektiğinde, geliştiriciler farklı bir adresle tamamen yeni bir sözleşme yayınlamak zorundadır. Bu kalıcılık güvenlik açısından harika olsa da, işler ters gittiğinde veya iyileştirme gerektiğinde sınırlayıcı olabilir.
Tarih, akıllı sözleşme güvenlik açıklarının felaketle sonuçlanabilecek finansal kayıplara yol açabileceğini göstermiştir. Bunun bir örneği, istismar edilebilir bir kusur nedeniyle milyonlarca dolarlık zarara yol açan büyük bir olaydır.
Bu olaylar, dağıtımdan sonra güvenlik sorunlarını ve hataları ele alabilmenin önemini ortaya koymaktadır. Sözleşmeleri yükseltilebilir hale getirmek, mevcut durumu ve kullanıcı deneyimini kaybetmeden sorunları düzeltmek için bir mekanizma sağlar ve bu, akıllı sözleşmelerin yükseltilebilirliğinin önemli bir yönüdür.
Bu yetenek, önemli kayıpları önlemek ve sistemin bütünlüğünü korumak için önemli olabilir.
Yükseltilebilir akıllı sözleşmeleri uygulamak için akıllı sözleşme proxy modelleri ve veri ayırma teknikleri gibi çeşitli yöntemler vardır. Bu makale, blok zinciri geliştirme alanında bu sorunu çözmek için yaygın olarak kullanılan bir yöntem olan proxy modellerini kullanarak yükseltilebilirliği nasıl uygulayacağınızı ele almaktadır.
Proxy Desenini Anlamak
Proxy modeli, bir sözleşmenin başka bir sözleşme için bir arayüzü uyguladığı yapısal bir tasarım modelidir. Bu mimari iki ana bölümden oluşur: proxy sözleşmesi ve uygulama sözleşmesi.
Kullanıcı, uygulama sözleşmesiyle doğrudan iletişim kurmak yerine, proxy sözleşmesi ile iletişim kuracak ve bu sözleşme talepleri uygun şekilde iletecektir.
Bu yapılandırmada, proxy sözleşmesi ve uygulama sözleşmesi dağıtıldıktan sonra değiştirilmez. Ancak, proxy'nin zaman içinde farklı uygulama sözleşmelerine başvurmasına izin vererek yükseltilebilirlik sağlanır.
Bu, kullanıcıların aynı adresi ve arayüzü kullanmaya devam edebilecekleri, ancak altta yatan işlevselliğin güncelleneceği anlamına gelir. Kullanıcı açısından, arka uç mantığı değişse bile uygulama mükemmel şekilde çalışmaya devam eder.
Proxy sözleşmesi, kullanıcı etkileşimlerinden ve tüm verilerin depolanmasından sorumludur. Uygulama sözleşmesinin adresini özel bir depolama alanında saklar.
Kullanıcılar proxy sözleşmesindeki işlevleri çağırdığında, bir yedek işlev çağrılır. Aşağıdaki işlev, uygulama sözleşmesinden kodu çağırmak için bir delegatecall ethereum mekanizması kullanır, ancak herhangi bir durum değişikliği proxy sözleşmesinin depolama alanında kaydedilir.
Başlıca Proxy Desen Uygulamaları
Şeffaf Proxy Modeli
Şeffaf Proxy Modeli, yükseltme işlevini proxy sözleşmesinin içine yerleştirir. Proxy, uygulama sözleşmesine işaret eden adresi güncellemek için kullanılan upgradeTo yöntemine sahiptir.
Bu, potansiyel bir sorun oluşturur: hem proxy hem de uygulama sözleşmeleri upgradeTo yöntemini içeriyorsa, kullanıcı bu işlevi çağırdığında hangisinin çağrılması gerektiği açık değildir.
Bu belirsizliği gidermek için, sözleşmeyi kimin çağırdığına bağlı olarak hangisine devredileceğine karar verilen bir çözüm geliştirilmiştir.
Arayan proxy yöneticisi ise, çağrılar proxy sözleşmesi tarafından işlenir. Aksi takdirde, çağrılar uygulama sözleşmesine devredilir. Bu yaklaşım, işlevlerin net bir şekilde yürütülmesini ve yönetici ile normal kullanıcı işlemleri arasında karışıklık olmamasını sağlar.
Evrensel Yükseltilebilir Proxy Standardı
Evrensel Yükseltilebilir Proxy Standardı, yükseltme işlevini proxy'ye değil, uygulama sözleşmesine yerleştirerek farklı bir yaklaşım sergiler. Proxy, tüm çağrıları yeni sürümleri işaret eden upgradeTo yöntemine sahip uygulama sözleşmesine delege eder.
Bu model, geliştiricilere yükseltme yolunda daha fazla kontrol sağlar. Bir geliştirici, gelecekteki bir sürümde upgradeTo yöntemini artık dahil etmemeyi seçerse, sözleşme artık kalıcı olarak değiştirilemez hale gelir ve daha fazla yükseltilemez.
Bu, bir sözleşme iyice test edildikten ve geliştirme ekibi onu son haliyle dondurmak istediğinde yararlı olabilir.
Yükseltme mantığı uygulama sözleşmesinde yer aldığından, proxy'nin yedek işlevi, çağrıları delege etmeden önce arayanın yönetici olup olmadığını kontrol etmek zorunda değildir.
Bu, kalıbı Şeffaf Proxy Kalıbından daha gaz verimli hale getirir. upgradeTo yöntemi yalnızca uygulama sözleşmesinde mevcut olduğundan, olası adlandırma çakışması da ortadan kaldırılır.
Beacon Proxy Modeli
Beacon Proxy Pattern, üç bileşenli bir mimari sunar: proxy sözleşmesi, beacon sözleşmesi ve uygulama sözleşmesi. Proxy, uygulamanın adresini kaydetmek yerine beacon sözleşmesinin adresini kaydeder.
Beacon sözleşmesi ise uygulama sözleşmesinin adresini içerir.
Bir kullanıcı proxy'yi çağırdığında, önce beacon sözleşmesinin adresini alır, ardından beacon'ı çağırarak uygulama sözleşmesinin adresini alır. Son olarak, uygulama sözleşmesine çağrı bırakır.
Bu ekstra dolaylı katman çok özel bir amaç için kullanılır.
Bu model, birkaç proxy sözleşmesinin aynı uygulamayı kullanması gerektiğinde özellikle yararlıdır. Daha basit modellerde, uygulamayı güncellemek için her proxy sözleşmesindeki adresi ayrı ayrı güncellemek gerekir. Beacon modelinde ise yalnızca beacon sözleşmesinin güncellenmesi gerekir ve bununla ilişkili tüm proxy'ler otomatik olarak yeni uygulamayı gösterir.
Başlıca Proxy Desen Uygulamaları
Elmas Proxy Modeli
Diamond Proxy Pattern, genellikle yaklaşık 24 kilobayt ile sınırlı olan akıllı sözleşmelerin boyut sınırlaması sorununu çözer. Bu model, işlevselliği "yüzler" olarak bilinen birkaç küçük sözleşmeye ayırır.
Proxy sözleşmesi, işlev seçiciler ile bu işlevleri içeren özelliklerin adresleri arasındaki eşleşmeyi korur.
Proxy üzerinde bir işlev çağrıldığında, işlev seçiciyi kullanarak işlevi içeren özelliği arar ve işlev çağrısını uygun özelliğe devreder.
Yükseltmeler, proxy'deki facet adreslerini değiştirerek yapılır. Bu model, işlevselliği birden fazla sözleşmeye dağıtarak ve her bir facet'in boyut sınırının altında kalmasını sağlayarak çok daha fazla toplam işlevsellik sağlar.
Proxy Desen Yaklaşımlarının Karşılaştırılması
Her proxy modeli, farklı kullanım durumları için uygun hale getiren farklı özelliklere sahiptir. Dört modelin tümü, çağrıları uygulama sözleşmelerine iletmek için proxy sözleşmesi ve kullanım delegasyonuna ihtiyaç duyar.
Şeffaf Proxy Deseni, Proxy Sözleşmesinde Yükseltme İşlevlerini Bulur ve UUPS, Uygulama Sözleşmesinde Yükseltme İşlevlerini Bulur. Beacon deseni, yükseltme özelliğini kendi beacon sözleşmesine koyar ve Diamond deseni genellikle yükseltme özelliğini uygulama sözleşmelerine koyar, ancak bu kesin olarak belirtilmemiştir.
Değişmezlik söz konusu olduğunda, UUPS ve Diamond kalıpları, gelecekteki sürümlerden yükseltme işlevini kaldırarak sözleşmeleri kalıcı olarak değişmez hale getirebilir. Transparent ve Beacon kalıpları bu esnekliği sağlamaz.
Birden fazla proxy ile çalışırken, Beacon modeli kesin bir avantaja sahiptir. Transparent, UUPS ve Diamond modellerinde, yeni bir uygulama gerçekleştirilirken her proxy ayrı ayrı değiştirilmelidir.
Beacon modelinde, yalnızca beacon sözleşmesi güncellenmelidir ve tüm proxy'ler otomatik olarak yeni uygulamayı kullanacaktır.
Gaz verimliliği her model için farklıdır. Şeffaf model, her yetkilendirme öncesinde arayanın yönetici olup olmadığını kontrol etmenizi gerektirir, bu nedenle daha pahalıdır.
UUPS, bu kontrolü gerektirmediği için daha verimlidir. Diamond hariç tüm desenler, ekstra arama işlemleri nedeniyle ekstra gaz maliyetine sahiptir.
Diamond hariç tüm modeller, sözleşme başına 24 kilobayt ile sınırlıdır. Diamond modeli, her bir yönün 24 kilobayt büyüklüğünde olmasına izin verir, bu da birden fazla yönde çok daha büyük bir toplam işlevsellik elde etmeyi mümkün kılar.
Akıllı Sözleşme Güvenliğini Ustaca Kullanın
Uzmanlar tarafından verilen kurslarımızla güvenli ve yükseltilebilir sözleşmeler oluşturmak için ileri düzey teknikleri öğrenin.
Önemli Hususlar ve Riskler
Depolama Çakışması Sorunları
Depolama çakışmaları, proxy kalıpları uygularken ciddi bir risktir. Sözleşme değişkenleri belirli depolama yuvalarında saklanır ve proxy sözleşmesinin değişkenleri ile uygulama sözleşmesinin değişkenleri aynı depolama yuvalarında saklanırsa, birbirlerini etkilerler.
Ayrıca, uygulama sözleşmesindeki değişkenlerin sırası bir sürümden diğerine değişirse, depolama yuvaları yeniden atanabilir ve bu da veri bozulmasına neden olabilir.
Başlatılmamış Uygulama Sözleşmeleri
Uygulama sözleşmeleri, geleneksel sözleşmelerdeki yapıcıya benzer bir kavram olan başlatma işlevi aracılığıyla tam olarak bir kez başlatılmalıdır.
Geliştiriciler ayrıca uygulamayı başlatmayı unuturlar veya başlatma işlevinin birden fazla kez çağrılmasını önlemek için korumalar eklemeyi unuturlar.
Bu durumda, saldırganlar başlatma işlevini kendileri çağırabilir ve sözleşmeyi kontrol altına alabilir veya durumunu manipüle edebilir.
Gerçek Dünyadaki Güvenlik Olayları
Bir hata ödül programı, uygulama sözleşmelerinin doğru şekilde başlatılmadığı vault proxy sözleşmelerinde kritik bir güvenlik açığı buldu. Bu kusur, bir saldırgan tarafından uygulama sözleşmesini yok etmek ve ilgili proxy sözleşmelerini kullanılamaz hale getirmek için kullanılabilirdi. Temmuz ayının belirli bir döneminde meydana gelen başka bir olayda, başlatma kodundaki güvenlik açığı nedeniyle akıllı sözleşmeler hacklendi; bu güvenlik açığı, başlatma işlevinin birden çok kez çağrılabilmesine neden oluyordu.
Yükseltilebilirliğe Alternatif Yaklaşımlar
Veri Ayırma Deseni
Proxy modellerine alternatif olarak veri ayırma yaklaşımı da kullanılabilir. Bu yaklaşım, depolama ve mantık için ayrı sözleşmelerin kullanılmasına dayanır. Mantık sözleşmesi, verileri okumak veya güncellemek için depolama sözleşmesi ile iletişim kurar.
Mantık sözleşmesi yeni sürümlerle değiştirilebilirken, depolama sözleşmesi sabittir ve değiştirilemez. Bu, bazı durumlarda uygun olabilecek farklı bir yükseltilebilirlik modeli sunar.
Doğrulama Katmanları
Yaygın olarak kullanılan proxy modellerinin hiçbiri, yükseltme yapılmadan önce yeni uygulama sözleşmesinin geçerliliğini doğrulama mekanizmasına sahip değildir.
Yeni sürümlerin gerekli tüm iş mantığını, yedek işlevleri ve diğer temel bileşenleri içermesi zorunludur.
Bu, proxy katmanı, iş mantığı katmanı ve depolama katmanının yanında bir doğrulama katmanı ekleyerek sağlanabilir. Bu ek katman, yükseltmelerin gerçekleştirilmesine izin verilmeden önce belirli kriterlere uymasını sağlar.
Yükseltilebilir Sözleşmeler için En İyi Uygulamalar
Yükseltilebilir sözleşmeler tasarlayan geliştiriciler, güvenlik ve güvenilirliği sağlamak için bazı temel yönergeleri izlemelidir:
- •Bunun yerine, kapsamlı bir şekilde incelenmiş ve denetlenmiş, iyi test edilmiş kütüphanelerden iyi test edilmiş uygulamalara güvenin.
- •Uygulama sözleşmelerini her zaman doğru şekilde başlatın ve başlatma işlevlerinin yalnızca bir kez çağrılabildiğinden emin olun.
- •Durum değişkenlerini asla bildirimlerinde veya yapıcıda başlatmayın, tüm durum ayarları için başlatma işlevini kullanın
- •Uygulama sözleşmelerinin yeni sürümlerini oluştururken durum değişkenlerinin sırasını veya türlerini değiştirmeyin.
- •Yeni değişkenler gerekiyorsa, mevcut tüm değişkenlerin sonuna eklenmelidir.
- •Diamond desen uygulamaları için, bu desen için optimize edilmiş özel depolama yöntemleri kullanın.
- •Mümkün olduğunda UUPS yöntemi, Transparent Proxy Pattern'a göre tercih edilir, çünkü rutin işlemler için daha az gaz gerektirir
- •Proxy yönetici hesabının yüksek güvenlikli olduğundan emin olun, çünkü bu hesap yükseltme sürecini kontrol eder ve kritik bir güvenlik noktasıdır
- •Son olarak, tüm sözleşmeleri, uygulanmadan önce deneyimli akıllı sözleşme güvenliği uzmanları tarafından profesyonel olarak denetlettirin.
Son Düşünceler
Proxy kalıpları, aynı adres ve durumu korurken akıllı sözleşmeleri yükseltmek için güçlü bir mekanizma sağlar. Proxy sözleşmesi, delegateCall kullanarak yürütmeyi uygulama sözleşmelerine aktarır, böylece kullanıcı arayüzünü değiştirmeden temel mantık değiştirilebilir.
Ancak, yükseltilebilir sözleşmeler düzgün bir şekilde uygulanmazsa, ciddi güvenlik açıklarına neden olabilirler.
Geliştiriciler, farklı proxy modelleri arasındaki dengeleri dikkatlice değerlendirmeli, yerleşik en iyi uygulamalara uymalı ve güvenilir ve güvenli, yükseltilebilir akıllı sözleşmeler oluşturmak için uygun güvenlik denetimlerinin gerçekleştirilmesini sağlamalıdır.
Proxy Kalıplarının Karşılaştırılması
Hangi proxy modelinin kullanılacağını karşılaştırırken, dikkate alınması gereken birkaç faktör vardır:
Proxy Desen Karşılaştırması
| Özellik | Şeffaf | UUPS | Beacon | Elmas |
|---|---|---|---|---|
| Yerini Yükselt | Vekalet Sözleşmesi | Uygulama Sözleşmesi | Beacon Sözleşmesi | Uygulama Sözleşmeleri |
| Kalıcı Değişmezlik | Hayır | Evet | Hayır | Evet |
| Birden Fazla Proxy | Bireysel Güncellemeler | Bireysel Güncellemeler | Tek İşaret Sinyali Güncellemesi | Bireysel Güncellemeler |
| Yakıt Verimliliği | Daha Yüksek Maliyet (Yönetici Kontrolü) | Daha Düşük Maliyet | Orta (Ekstra Arama) | Orta (Yüz Arama) |
| Sözleşme Boyutu Sınırı | 24 KB | 24 KB | 24 KB | Faset başına 24 KB |
| Uygulama Karmaşıklığı | Orta | Orta | Orta | Orta |
Desen Seçimi ile İlgili Hususlar
Desen seçimi için önemli hususlar:
- •Tüm modellerin bir proxy sözleşmesi olması ve çağrıları iletmek için delegasyon kullanması gerekir
- •Şeffaf Proxy Modeli, yükseltme işlevlerini proxy sözleşmesinin içinde depolamak için kullanılır.
- •UUPS, yükseltme işlevlerini uygulama sözleşmesine koyar
- •Beacon modeli, yükseltmeler için ayrı bir beacon sözleşmesi kullanır.
- •Diamond modeli genellikle yükseltme işlevlerini uygulama sözleşmelerine yerleştirir, ancak spesifikasyon bunu zorunlu kılmaz
- •Yalnızca UUPS ve Diamond desenleri, gelecek sürümlerden yükseltme işlevini kaldırarak sözleşmeleri kalıcı olarak değiştirilemez hale getirme seçeneğine sahiptir.
- •Beacon modeli, aynı anda yükseltmeniz gereken birden fazla proxy varsa idealdir, çünkü beacon'ın yükseltilmesi yeterlidir, her proxy'nin yükseltilmesi gerekmez.
- •Transparent, UUPS ve Beacon desenleri için maksimum sözleşme boyutu 24 kilobayttır.
- •Diamond modeli, her bir yüzün 24 kilobayt kadar büyük olmasını destekler, böylece çok daha büyük bir toplam işlevsellik desteklenebilir
- •Tüm desenlerin uygulama karmaşıklığı orta düzeydedir ve Transparent, UUPS ve Beacon desenleri için iyi kurulmuş kütüphaneler mevcuttur.
