Radix Engine: “Kutsallaştırma” için Daha İyi Bir Model

Benim .. De önceki makale , Radix Engine'in Sui'nin MoveVM'sindeki bazı kusurlardan nasıl kaçındığını inceledim. Özetlemek:

• Sui'nin MoveVM'si çok düşük seviyeli ve genel olduğundan hantal bir DeFi programlama ortamı yaratıyor.
• Radix Engine, üst düzey ve varlık + iş mantığı odaklı olup, geliştiricilerin düşük düzeyli ayrıntılar yerine DeFi mantığına odaklanmasına olanak tanır.

Sui'nin MoveVM'si orijinali takip ediyor Ethereum felsefesi Her şeyi uygulama katmanına devreden "temiz, basit, güzel" bir protokolün. Bu, geliştiricilere o anda bilinmeyenler de dahil olmak üzere herhangi bir alanı keşfetme özgürlüğü sağlar.

Ancak çok basit ve yapılandırılmamış bir protokol önemli tavizler doğurur. Örneğin, yetkilendirme gibi yaygın sistem özellikleri, uygulama alanında karmaşık bir uygulama gerektirebilir, standart arayüzler daha parçalı hale gelebilir ve performans optimizasyonu daha zor hale gelebilir.

Öte yandan Radix Engine, aşağıdakileri yapmamıza olanak tanıdığı için genel olmayan, sistem çapındaki mantığı temel bir teknik hedef olarak yürütmek üzere tasarlanmıştır:

• Sistem çapında standartları/uygulamaları uygulayın . Görüşlü bir standart, API'ler parçalı olmadığından (örneğin, ERC-20, ERC-721 ve ERC-404) geliştirme/sürdürülebilirlik/araç oluşturmanın yığın genelinde daha kolay olmasına olanak tanır ve davranışın anlaşılması bayt kodu yorumlaması gerektirmez (artık yok) ERC-20 halı çeker). Bu, geliştiricilere ve son kullanıcılara daha güvenli, daha tutarlı bir DeFi deneyimi sunar.
• Mantığı donanıma daha yakın yürütün . Sistem mantığının doğruluk açısından bir yorumlayıcı tarafından çalıştırılmasına gerek olmadığından, bu mantığın yürütülmesi donanıma mümkün olduğunca yakın çalıştırılabilir.
• Yürütmeyi paralelleştirin. Belirli nesnelerin davranışları hakkında önceden bilgi sahibi olunması, yürütmeden önce statik analiz kararlarının alınmasını kolaylaştırır ve paralel yürütmeye olanak tanır.

Vitalik yakın zamanda bu fikre “ kutsal yer ”veya protokolün zorladığı mantığın faydalarını elde etmek için soyutlamadan seçici olarak kopma fikri. Fotoğraflarından birini çalarak sorunu soyutlama ile kutsallaştırma arasındaki bir denge olarak çerçeveliyor:

Performans/güvenlik/kullanılabilirliği (yani kutsallaştırma) korurken soyutlamayı (yani gelecekteki/çeşitli kullanıcı ihtiyaçlarını) destekleme dengesi aslında çok eski bir bilgisayar bilimi problemidir. İşletim Sistemlerinin tasarımı özellikle son yıllarda benzer bir sorunu çözmeye çalışmaktadır: Hızlı, güvenli ve kullanışlı bir sistemi korurken bir dizi soyut uygulamayı nasıl destekleriz?

Bu makalede, Vitalik'in korktuğu protokol karmaşıklığı veya esneklik kaybı olmadan her türlü "kutsallaştırma" kapasitesine sahip bir çerçeve oluşturmak için Radix Engine'in İşletim Sistemi modelini nasıl kullandığını ele alacağım.

Mevcut endüstri standardı olan Ethereum Sanal Makinesine (“EVM”) bakarak başlayalım.

VM olarak EVM

EVM, aşağıdaki işlem kodlarıyla bir sanal makine ("VM") olarak modellenebilecek kadar basittir:

• Turing-tamamlanmış işlem kodu seti
• Diğer akıllı sözleşmelere yapılan çağrılar için işlem kodları
• Mevcut akıllı sözleşmenin sahip olduğu kalıcı depolamaya okuma/yazma işlem kodları

EVM bayt kodunda derlenen akıllı sözleşmeler daha sonra böyle bir VM'nin üzerinde yürütülebilir.

Bu modelde, herhangi bir "kutsallaştırma" biçimi, EVM veya VM donanımında değişiklik yapılmasını gerektirir. Örneğin, BLS imza desteğinin kutsallaştırılması, yeni bir ön derlemenin eklenmesini gerektirir. Uygulama EIP-2938 yeni işlem kodlarının eklenmesini gerektirir. Kutsal olanın genişletilmesi kaçınılmaz olarak daha büyük, daha karmaşık bir VM ile sonuçlanır ve protokol tasarımcısını Vitalik'in tanımladığı şu ya da bu kararı vermeye zorlar.

Bu modeldeki genel sorun, Soyutlama/Kutsallaştırma ikileminin Yazılım/Donanım ikilemiyle fazla bağlantılı olmasıdır. Yani herhangi bir mantığı protokole dahil etmek, onu VM'ye gömülmeye zorlar. “Kutsal yazılım” ya da sistemin parçası olan yazılımı ifade etmenin bir yolu yoktur.

İşletim Sistemleri bu ikilemi “sistem yazılımı” kavramıyla çözdü. Hadi daha yakından bakalım.

İşletim Sistemi Modeli

Bir İşletim Sisteminin ana hedeflerinden biri, yazılım/donanım ikilemini veya daha spesifik olarak uygulama/donanım ikilemini yönetmektir. Herhangi bir İşletim Sisteminin temel kısmı, kullanıcı alanı uygulamalarını ve bunların donanıma erişimini yöneten yazılım olan çekirdektir. Çekirdek modülleri ve sürücüleri, desteklenen donanım kümesini genişleten veya çekirdek işlevselliğini genişleten ek sistem yazılımı parçalarıdır.

\“Kutsallaştırma” perspektifinden bakıldığında, çekirdek ve modülleri sistemin kutsallaştırılmış parçalarıdır ancak yazılımın esnekliğine sahiptir. Çekirdek modülleri, sanal makineler ("VM'ler") ve kullanıcı alanı sistem süreçleri, bunlar çekirdeğin kendisinden soyutlanmış olduğundan daha da "yumuşak"tır.

Bu modelde, uygulamalar ve donanım arasındaki dolaylılık katmanı, yazılım/donanım ikileminin soyutlama/kutsallaştırma ikileminden ayrılmasına olanak tanır. “Sistem yazılımı” donanıma aşırı yük bindirmeden koruma sağlar.

İşletim Sistemi Olarak Radix Engine

Bu işletim sistemi modelini ilham kaynağı olarak kullanan Radix Engine, her biri belirli bir sorumluluğa ve soyutlamaya sahip olan ve sistem modülerliğine ve takılabilirliğine olanak tanıyan birden fazla katman içerir.

Böyle bir modüler tasarım, sistem mantığının uygulanmasına olanak tanırken aynı zamanda aşağıdakilere de izin verir:

• İçinde bulunduğu katmanın yalıtım özelliklerini devralın . Örneğin, koruma altına alınmış bir paket, koruma altına alınmış olmasına rağmen isteğe bağlı duruma erişemez ancak uygulama katmanı sınırlarını takip etmelidir. Bu, kullanıcı alanı sürücülerinde veya mikro çekirdek tasarımında görülen benzer bir güvenlik türüdür. Yani, sistemdeki herhangi bir güncellemenin (kutsallaştırma) tüm sistemi riske maruz bırakmaması için sistemin her bir parçası yalıtılarak risk azaltılır.
• İçinde bulunduğu katmanın özelliklerine erişin. Örneğin, korunan bir paket, sistem tarafından sağlanan kimlik doğrulama ve/veya yükseltilebilirlik özelliklerini devralabilir.
• Yönetişimi ayırın. Bu modüler tasarım, bu modüllerin her birinde yeniliğin paralel ve farklı hızlarda gerçekleşmesine olanak tanır.

Şimdi bu katmanların her birinin üzerinden geçelim ve sorumluluklarının neler olduğunu görelim.

Uygulama katmanı

Uygulama katmanı, üst düzey mantığın tanımlanmasından sorumludur. Bu mantığı açıklayan bayt kodu, diğer statik bilgilerle birlikte Paket adı verilen yürütülebilir bir formatta paketlenir. Paketler daha sonra defterde saklanır ve yürütülmeye hazır hale gelir.

DeFi geliştirme için geliştirdiğimiz Rust tabanlı dil olan Scrypto'da yazılan uygulamalar bu katmanda yaşar. Scrypto programları, programın sistem/çekirdek hizmetlerine erişmesine olanak tanıyan bir dizi işlev aktarımına erişimle WASM programlarında derlenir. Bu Sistem Çağrısı API'si Linux'a benzer sistem çağrıları , paylaşılan G/Ç'ye erişim sağlar.

VM Katmanı

Bir sonraki katmana geçildiğinde VM katmanı, uygulama katmanı için bilgi işlem ortamının sağlanmasından sorumludur. Buna Turing-complete VM'nin yanı sıra sistem katmanına erişim sağlayan arayüz de dahildir.

Radix Engine şu anda iki VM'yi desteklemektedir: Scrypto uygulamalarını yürütmek için kullanılan bir Scrypto WASM VM ve ana bilgisayarın ortamında derlenen yerel paketleri yürüten yerel bir VM.

Özellikle Scrypto WASM VM'ye bakarsak şöyle görünür:

Bu aslında EVM modeliyle aynı görünebilir ancak iki önemli fark vardır:

• Depolamaya doğrudan erişimin kaldırılması. Her akıllı sözleşmenin yalnızca kendisine ait depolama alanına erişebilmesi yerine, herhangi bir durum okuma/yazma işlemi sistem çağrıları aracılığıyla gerçekleştirilir. Bu dolaylılık katmanı, uygulamalar arasında durum paylaşımı, durum sanallaştırması vb. gibi birçok ilginç şeyin sistemde uygulanmasına olanak tanır. Bu dolaylılık katmanı, tarafından sağlanan dolaylılamaya benzer. sanal bellek veya Linux'un dosya tanımlayıcıları .

  
  

• Sistem çağrılarının eklenmesi . Sistem çağrıları, uygulama katmanının, diğer uygulamalara çağrı yapma veya bir nesneye veri yazma gibi Sistem katmanı hizmetlerine erişebildiği mekanizmadır. Bu sistem çağrıları, gerçek CPU'lardaki yazılım kesme talimatlarına benzer (örn. Dahili x86'daki talimat).

Sistem Katmanı

Sistem Katmanı, sistemin işlevselliğini artırabilecek bir dizi Sistem Modülünün veya takılabilir yazılımın bakımından sorumludur. Bunlar Linux'unkine benzer çekirdek modülleri .

Her sistem çağrısında, sistem katmanı kontrolü çekirdek katmanına geçirmeden önce her sistem modülü çağrılır. Çağrıldığında, her sistem modülü belirli bir durumu güncelleyebilir (örneğin, harcanan güncelleme ücretleri) veya işlemi sonlandırmak için panik yapabilir (örneğin, tür denetleyicinin başarısız olması durumunda).

Bu model, sistemin hem uygulama hem de çekirdek katmanlarından ayrılırken yetkilendirme, telif hakları veya tür kontrolü gibi işlevleri uygulamasına olanak tanır.

Çekirdek Katmanı

Çekirdek katmanı, Radix Engine'in iki temel işlevinden sorumludur: depolama erişimi ve uygulamalar arasındaki iletişim. Bu, geleneksel İşletim Sisteminin disk ve ağ erişimi sorumluluğuna biraz benzer.

Radix Engine için bu, aşağıdaki alt düzey yönetimi içerir:

• Herhangi bir çağrı veya veri yazma işleminde taşıma/ödünç alma semantiğinin korunup korunmadığını kontrol edin. Tek sahip kuralı ve ödünç alma kuralları çekirdek tarafından uygulanır. Bu kurallardan herhangi birinin başarısız olması durumunda işlem paniğe kapılacaktır.
• Geçici ve kalıcı nesneleri yönetin. Bir nesne herhangi bir zamanda küresel uzayda olabilir veya bir çağrı çerçevesine ait olabilir. Çekirdek, bu nesnelere yapılan referanslar aktarılırken, çalışma zamanı sırasında bu nesnelere yönelik doğru işaretçileri korur.
• İşlem durumu güncellemelerini yönetin. Çekirdek, bir işlem sırasında meydana gelen ve işlemin sonunda veritabanına kaydedilecek olan durum güncellemelerini takip eder.

Kutsal Yazılım

Bu katmanların bir DLT protokolündeki korumayla ilişkisi nedir? İşletim Sistemlerindeki çekirdek katmanına benzer şekilde, Radix Engine'in bu orta katmanları, soyutlama/kutsallaştırma ikilemini yazılım/donanım ikileminden ayırmak ve "kutsallaştırılmış yazılım" kavramını yaratmak için gereken yönlendirmeyi sağlar.

Kutsal yazılım, sistem genelinde mantığı uygulama yeteneğini korurken, yazılımın esneklik ve güvenlik özelliklerine sahiptir.

Şu anda Radix ağında çalışan birkaç kutsallaştırma örneğini inceleyelim ve bunların nasıl uygulandığını görelim.

Kutsal Kaynaklar

Radix DeFi/Web3 platformunun temel farklılığı, bir kaynağın (yani varlığın) iş mantığından ayrı olarak anlaşılması gereken temel bir ilkel olduğu fikridir. Bu konseptin benimsenmesi, tüm dApp'lerin, cüzdanların ve araçların bir varlığın arayüzünün ve davranışının neye benzediğine dair ortak bir anlayışa sahip olmasını sağlayarak şekillendirilebilirliği çok daha kolay hale getirir.

Kaynaklar sistemin en köklü parçalarından biri olmasına rağmen, bunların kutsallaştırılmasının uygulanması yalnızca iki modüler yazılım parçası gerektirir:

• Buckets, Vaults ve Proofs gibi kaynak nesnelerinin mantığını işleyen yerel bir paket

• Bu nesnelerin ömür boyu değişmezlerini (kaynakların taşınabilirliği ve yakılabilirliği gibi) zorlayan bir sistem modülü

  
  

Radix Engine'in sistemden/çekirdekten soyutlanırken standartlaştırılmış, taşınabilir bir kaynağın derin konseptini ifade edebilmesi, modüler sistem yazılımı çerçevesinin gücünü gösterir.

Kutsal Yetki ve Telif Hakları

Radix Engine, bu mantığı iş mantığından ayırarak ve bunları sistem özellikleri olarak uygulayarak yetkilendirme ve telif haklarını standartlaştırır. Bu, kullanıcıların ve geliştiricilerin, defterdeki herhangi bir işleve erişme gereksinimlerini anlamak için yerleşik bir ortak yola sahip olmalarını sağlar.

İş mantığını sistem mantığından ayırmanın modülerliği aynı zamanda normal kimlik doğrulama kontrolleri olmadan bir işlemin önizlemesini görme yeteneği gibi uygun geliştirme/hata ayıklama seçeneklerine de olanak tanır (bir yere 10 milyon USDC göndermenin sonucunu simüle etmek ister misiniz? Yetkilendirme devre dışı bırakıldığında, önizleme işleminiz basımı yapın!).

Kimlik doğrulama ve telif haklarının korunması dört parça modüler yazılım gerektirir:

• Uygulama katmanının herhangi bir nesnenin yetkilendirme/telif haklarına erişmesine olanak tanıyan Kimlik Doğrulama ve Telif Hakları yerel paketleri (örneğin, bir yönteme erişmek için kimlik doğrulama kuralını almak veya telif haklarını talep etmek için).

• Kimlik Doğrulama ve Telif Ücretleri sistem modülleri, arayanın aramayı yapmak ve telif ücretlerini toplamak için yeterli yetkiye sahip olup olmadığını doğrulamak için bir nesne yöntemi çağrısından önce çağrılır.

  
  

  
  

Kutsal İşlem

Kullanıcı ile sistem arasındaki doğru arayüz, herhangi bir sistemin kullanılabilir olması için çok önemlidir. Kullanılabilir olması için arayüzün kullanım kolaylığı ile güç/esneklik arasında doğru dengeyi bulması gerekir.

İşletim Sistemi dünyasında en yaygın arayüz, kullanıcıya çeşitli sistem çağrılarını aramak ve oluşturmak için bir komut satırı aracı sağlayan bir kullanıcı alanı işlemi olan terminaldir.

DLT dünyasında bu arayüz işlemdir. Bir işlem için endüstri standardı, tek bir düşük seviyeli genel çağrı çağrısının kullanılmasıdır. Ne yazık ki bu çok basittir çünkü sistemle etkileşime girerken kişinin gerçekte ne yaptığını anlamayı zorlaştırır.

Öte yandan Radix Engine, geleneksel işletim sistemi modelini kullanır ve sistem çağrılarını tek bir işlemde çağırmak ve oluşturmak için bir uygulama dilini (bash gibi terminal komut dosyası diline benzer) barındırır.

Bir işlemin giriş noktası uygulama katmanında çalıştığından, dil yorumlayıcısı bir İşlem İşlemcisi yerel paketi eklenerek uygulanır.

Kutsal BLS

BLS imzaları, eşik imzaların olasılığına izin verdikleri için önemli bir kripto ilkeldir. Ne yazık ki, WASM'de bu tür bir mantığı çalıştırmak, maksimum maliyet birimini hızlı bir şekilde tüketir. Son “Anemone” güncellemesinde, BLS'yi yerel olarak çalıştırarak kutsallaştırdık ve WASM ile karşılaştırıldığında performansta 500 kat artış bulduk.

BLS mantığı durum bilgisiz olduğundan, Scrypto WASM VM'ye ek bir ön derleme olarak kolayca eklenebilir.

Çözüm

Herhangi bir DLT protokolü için neyin kutsanacağı ve neyin kutlanmayacağı önemlidir. Maalesef endüstrinin mevcut VM modeli, her kutsallaştırma kararını yüksek riskli bir karar haline getiriyor.

İşletim Sistemi modelinden ilham alan Radix Engine, "yazılım" ve "donanım" arasına bir dolaylı katman ekleyerek bu sorunu çözüyor. Bu, Radix Engine'in "kutsal yazılım" kavramını ifade etmesine olanak tanır ve protokolün yüksek riskli uzlaşma kararları vermeden yeni korunan sistemleri eklemesini, değiştirmesini ve ifade etmesini kolaylaştırır.

Başlangıçta işletim sisteminin, birden fazla uygulama için paylaşılan kaynakları yönetmek üzere tasarlanmış küçük bir yazılım parçası olması gerekiyordu. Kullanıcının daha iyi, daha hızlı, daha güvenli bir platforma yönelik talepleri arttıkça, giderek daha geniş bir yazılım paketiyle giderek daha fazla sorumluluk üstlendi.

DeFi da farklı olmayacak. Daha hızlı, daha güvenli ve daha kullanışlı bir DeFi platformuna olan talep arttıkça, koruma da artacaktır. Radix Engine, bu düşünceyle tasarlandı ve kutsal alanı geleceğe genişletmek için gereken ölçeklenebilir ve güvenli çerçeveyi sağlıyor.