RDX Works Baş Protokol Mimarı Josh Primero'dan bir görüş yazısı.  Babylon ağında Radix Engine V2'yi piyasaya sürdükten sonra, DeFi sahnesinde ortaya çıkan yeni VM dalgasına daha yakından baktım. Bunlardan en ilgi çekici olanlarından biri, Diem'in orijinal MoveVM'sine göre bir gelişme olan Sui'nin MoveVM'sidir.  Sui'nin mimarisi bir süredir beni heyecanlandırıyor çünkü Radix ile birkaç önemli teknik felsefeyi paylaşıyor:  Varlık odaklı programlamayı etkinleştirmek için taşıma semantiğinin kullanılması.  Kısmi sıralama yoluyla fikir birliğini ölçeklendirmek için durum bağımlılıkları bilgisinden yararlanın (günün modası olan aşırı soyutlama ve ölçeklenebilirliği daha yüksek bir katmana taşımak yerine)  Teknik olarak konuşursak, bir dili ve bir mantığı yürütmek için gereken minimum durum bağımlılıklarını statik olarak yakalayan derlenmiş bir bayt kodunu nasıl kullandıklarını çok güzel buldum.  Bu yalnızca hızlı yürütmeyle sonuçlanmakla kalmaz, aynı zamanda bir işlemin durum bağımlılıkları ve durum yazmaları iyi sınırlandığından güvenlik avantajları da sağlar.  Ancak bu başarının bir bedeli var. DeFi programcıları, EVM'nin iyi bilinen sorunlarını tekrarlayan, daha zor ve zaman zaman sezgisel olmayan bir modeli yönetmek zorundadır.  Şimdi Sui'nin VM'sinde dört kusur olarak bulduğum bu sorunlara bakalım.  1. Çok Genel Olan İlkel Nesne  Sui'nin MoveVM'sinin (veya genel olarak MoveVM'nin) en büyük yeniliği, bayt kodu katmanında taşıma/ödünç alma semantiğinin kullanılmasıdır. Bu, onların düşük seviyeli makinelerinin nesnelerin sahipliğini ve hareketini anlayabildiği anlamına gelir; oldukça havalı!  Sui'nin VM'sindeki her nesne böylece  , sahiplenilebilen, taşınabilen ve paylaşılabilen ilişkili mantığa sahip yazılan bir değer.    NFT gibi davranır  Ne yazık ki, bu modelde bir nesne çok daha genel şeyler yapabildiğinden, DeFi programcısı karmaşık bir nesne yaşam boyu durum makinesini tanımlamak ve yönetmekle yükümlüdür.   Özellikle Sui'de yeni bir yapı tanımlarken programcının her biri durum makinesini farklı şekillerde etkileyen 4 yeteneğin ("kopyalama", "bırakma", "anahtar" ve "saklama") birleşimini belirtmesi gerekir. Ayrıca bir programcının, örnekleme sırasında bir nesnenin paylaşılması, aktarılması, değer olarak döndürülmesi veya dondurulması gerekip gerekmediğini yönetmesi gerekir.  Bunlardan herhangi birinde yanlış konfigürasyona sahip olmak, para kaybına yol açabilecek ince hatalara neden olabilir.  Örneğin aşağıdaki kodda Sui'yi kullanıyoruz.  basit bir flaş kredi uygulamak. Sorun? Düşürme özelliğini yanlışlıkla Makbuz'a ekledik.    Sıcak Patates Kalıbı  Bu küçük hata, borçlunun makbuzu bırakarak krediyi geri ödemeden kaçmasına neden olur. (FlashLoan ve Makbuz ilişkisinde başka bir hata daha var, bakalım bulabilecek misiniz!)  Bu nedenle, bir programcının bakış açısına göre, bir VM'yi bir dizi yetenekle tek bir nesne soyutlaması etrafında düzenlemek kavramsal olarak zarif ve basit olsa da, her birinin yansımalarını anlamak zordur çünkü gerçekleştirilecek çok fazla düşük seviye durumu vardır. üstesinden gelmek.  Bu, eski dillerin bellek yönetimi sorunlarına ve çöp toplayan VM'lerin neden bu kadar başarılı olduğuna çok da benzemiyor. Uygulama programcıları, belleğin serbest bırakılmasının ne zaman uygun olacağı gibi düşük düzeyli durumları yönetmeyi umursamazlar; nesnelere ve bu nesneler arasındaki ilişkilere önem verirler.  Benzer şekilde, DeFi programcıları temel olarak varlıklara ve bu varlıkların hareketi ve mülkiyetine ilişkin mantığa önem veriyor. Varlıkların kendi başlarına bir mantığı yoktur ve bu varlıkları yöneten mantığın "taşınması" veya "sahip olunması" gerekmez.  Sui'nin MoveVM'si, bu iki farklı şeyi tek bir genel nesne soyutlaması olarak birleştiriyor ve bu da DeFi programlama zihinsel modelini zorlaştırıyor.  2. Dinamik Gönderim Yok  MoveVM'nin tanımlayıcı bir özelliği, statik gönderim kullanmasıdır; bu, bir işlev çağrısı ile çalışma zamanı sırasında yürütülmesi arasında hiçbir dolaylı katman olmadığı anlamına gelir. İşlev çağrıları ve onun temelindeki mantık, yeni bir paketin yayınlandığı sırada statik olarak bağlantılıdır. Bu, VM'nin hızlı ve öngörülebilir olmasını sağlar ancak daha az esneklik ve kullanımı daha zor bir programlama ortamı pahasına olur.  Dinamik gönderim eksikliğinin üç yansımasına bir göz atalım.  2a) İşlevsiz Bileşim  VM'nin kod yayınlama sırasında çağrılacak işlevi tam olarak bilmesi gerektiğinden, farklı işlevleri bir arada oluşturmak imkansızdır; normal programlamada çok yaygın bir kalıp (örneğin, OO dillerindeki arayüzler veya Rust'taki özellikler).  Basit bir Likidite Havuzu teşvik edicisine bir göz atalım. Eğer Rust'taki katkınıza %10 oranında katkı sağlayacak bir teşvik edici madde yazsaydım, şöyle görünürdü:   Bu şekilde LiquidityEnhancer'ım, Havuz özelliğini uygulayan herhangi bir havuzla çalışacaktır (Evet, siz Rust titizleri için bu özellik de statik olarak bağlantılıdır. Bu sadece işlev kompozisyonunun bir örneğidir).  “Katkıda bulunmanın” önceden tanımlanmış bir işlev olması gerektiğinden bu Sui'de imkansızdır. Bunun yerine, herhangi bir yeni havuz uygulaması için tam havuz uygulamalarına bağlantı veren yeni bir paketin yayınlanması gerekecektir.  2b) Dinamik Geri Arama veya İşlev İşaretçisi Yok  Buna bağlı olarak, bazı genel arayüzler aracılığıyla rastgele mantığı çalıştırabilmek, özellikle DeFi ortamında çok faydalı bir yapıdır.  Gelecekte arayan kişiyi keyfi bir mantıkla (örneğin, gecikmiş ödemelerin kullanımı için) arama yapmaya teşvik eden, gelecekte teşvik edilmiş bir icracı hayal edin. Rust'ta bu şöyle görünecektir:   Ancak Sui'de dinamik gönderimin olmaması nedeniyle bu mümkün değildir. Bunun yerine, böyle bir özelliği kullanmak isteyen her yöntem için yeni bir IncentivizedFutureExecution paketinin yayınlanması gerekecektir.  2c) Garip Yükseltilebilirlik  Sui'nin desteği var  . Ne yazık ki, statik dağıtım değişmezliği nedeniyle paket yükseltmelerini yönetmek, beklenenden daha karmaşık ve daha az güvenlidir.   Paket yükseltme ve sürüm oluşturma  Öncelikle kesintisiz ve şeffaf kod güncellemeleri mümkün değildir. Başka bir pakete çağrı yapan bir paketim varsa ve diğer pakette gerekli hata düzeltme güncellemesi varsa, düzeltmeyi istersem kendim yeni bir paket yayınlamam gerekir.   Giderek daha fazla paket bağımlılığıyla bu, çok kullanılan bir pakette basit bir hata düzeltmesinden bile kolayca paket yükseltme patlamasına yol açabilir.   İkinci olarak, bu kodda hatalar ve/veya kötü amaçlı kodlar bulunsa bile tüm eski kodlar her zaman mevcut olacaktır (buna bağlı herhangi bir kodun onu çağırabilmesi gerekeceği için gereklidir). Bunu ortadan kaldırmak için, nesnelerin durumunda mantıklı bir sürüm oluşturma şemasını koruma yükü uygulama katmanına yüklenir.  3. Tuhaf Bir Posta Kutusu Modeli  Sui yakın zamanda bir yayınladı  Bu en iyi şekilde, bir nesneyi diğer nesnenin haberi olmadan başka bir nesneye göndermenin bir yolu olarak tanımlanabilir (daha önce bu yalnızca Adreslerle mümkündü). Bu nesneye erişebilmek için bu aktarımın bilgisine sahip ayrı bir işlemin yürütülmesi gerekir.    Nesneye Aktarım Kalıbı  Böyle bir yapı, alıcı nesnenin durumuna bağımlılığın ortadan kaldırılmasında faydalıdır; UTXO'ları UTXO modelindeki başka bir adrese göndermekten farklı değildir (alma kısmı aynı zamanda UTXO tanık komut dosyaları aracılığıyla sahipliğin kanıtlanmasına da benzer). Sui'nin fikir birliği daha sonra bu çekişme eksikliğinden faydalanabilir ve böyle bir işlemi daha iyi paralel hale getirebilir.  Ancak böyle bir performans artışının güvenlik açısından ödünleşimleri de yok değil. Nesnelerin, alıcı nesne hakkında bilgi olmadan (var olup olmadığı dahil!) alınabilmesi, gönderilen nesnelere erişimin sonsuza kadar kaybedilmesi olasılığını doğurur.  Alıcı nesne gönderilen nesneyi desteklemiyorsa bu mümkündür. Böyle bir kusur, bir ERC-20 tokenını, o tokenı desteklemeyen bir akıllı sözleşmeye yanlışlıkla göndermeye benzer (fon kaybının   yaygın bir nedeni). çok  Ayrıca, biri ebeveynin çocukları hakkında bilgi sahibi olduğu, diğeri çocukların ebeveynleri hakkında bilgi sahibi olduğu iki tür ebeveyn-çocuk ilişkisinin olması, geleneksel programlamada tipik olandan daha karmaşık bir model oluşturur.   Bu garip yapı üzerinde programlama yapmadan performans avantajlarını koruyan bir yaklaşım var mı? Var olduğuna inanıyorum. Diğer CRDT yaklaşımlarıyla birlikte değişmez işaretçilerin kullanılmasını gerektirir, ancak bunu gelecekteki bir makalede ele alacağım.  4. Garip Paylaşılan Durum Programlaması  Sui'nin VM'si çekişmeli olmayan bir durum için programlama yapmak ve bu durumu yürütmek üzere optimize edilmiştir. Bu, aslında paylaşılan durumla uğraşmak gerektiğinde bazı garip programlama mekaniklerine yol açtı. Gelin bunlardan bazılarına bir göz atalım.  4a) Kayıtlı Referans Yok  Sui'nin VM'sinde kayıtlı referans kavramı yoktur. Eğer öyle olsaydı, bir fonksiyonun durum bağımlılıklarını statik olarak analiz etme ve dolayısıyla paralelleştirme yeteneğini kaybederdi. Bunun sonucu olarak, saklanan referansları yönetme yükü artık programcıya/kullanıcıya yüklenmiştir.  Örneğin, işlevlerinden birinde belirli bir Oracle'dan fiyat gerektiren bir nesnem olduğunu varsayalım. Rust'ta bu şöyle görünebilir:   Sui'de referanslar saklanamadığı için MyDefi ile Oracle arasındaki bu ilişkinin daha işlevsel bir şekilde anlatılması gerekir:   Fakat bekle! Artık herhangi bir keyfi kehanet aktarılabilir. Doğru kehanetin kullanıldığından emin olmak için,  kullanılması gerekir:    Kimlik İşaretçisi Deseni  Bu kalıp, normal referanslarla karşılaştırıldığında daha kırılgandır ve doğru ilişkinin uygulanmasına dikkat edilmelidir. Nesneler arasındaki ilişki grafiği büyüdükçe ve daha karmaşık hale geldikçe, bu programlama yükünün çok iyi ölçekleneceğini hayal etmek zordur (örneğin, Oracle get_price çağrısının da kendi bağımlılıkları varsa).  Ayrıca, ister bir işlem ister paket kodu olsun, arayan kişinin üzerinde her zaman doğru referansı iletme yükü olacaktır. Bu referans değişebilirse, bu, referansın en son duruma güncellendiğinden emin olmak için arayan kişiye başka bir ek yük getirir.  4b) İlgili Örnekler İçin Dinamik Olmayan Tip Güvenliği  Geleneksel programlamanın aksine DeFi programlamada, bir örneğin başka bir örnekle aynı "örnek grubunun" parçası olup olmadığını kontrol edebilmek çok kullanışlıdır.  Örneğin, iki madeni paranın birleşiminin aynı madeni para tanımlayıcısına ait olup olmadığını kontrol etmek güzel olurdu:   Bunu geleneksel jenerik anlambilimle uygulamadaki sorun, jeneriklerin "bir grup ilgili örneği" değil, türleri temsil etmek için kullanılmasıdır.  Oldukça akıllıca bir şekilde Sui, bu soruna çözüm bulmayı başardı.  . Bu sistem destekli modelde temel olarak şunu söylediler: İlgili örneklerden oluşan yeni bir grup istiyorsanız, bu grubun tanımlayıcısını temsil edecek bu özel yeni türü yaratın.   Bir Kezlik Tanık modeli  Bunun büyük bir yararı, dil katmanının hiçbir şekilde değişmesine gerek olmaması ve bu tür bir güvenliği sağlamak için iyi bilinen genel anlambilimin kullanılabilmesidir.  En büyük kusur, her yeni ilgili şey grubu oluşturulduğunda yeni bir türün (ve dolayısıyla yeni bir paketin) konuşlandırılması gerekmesidir. Örneğin yeni bir paket dağıtmadan dinamik olarak yeni bir Coin<T> oluşturulamaz.   Çözüm  Sui'nin MoveVM'si, sistem mühendislerinin standartlarına göre oluşturuldu: kavramsal olarak basit, düşük seviyeli temellere dayanan, statik olarak uygulanan bir VM.  Ne yazık ki basit, kolay anlamına gelmez ve normal paylaşılan nesne kalıplarından kaçınma konusundaki ısrarları, uygulama katmanlarının oldukça karmaşık olmasına ve programlamanın sezgisel olmamasına neden olur.  DeFi, dağınık, paylaşılan bir nesne dünyasıdır: herkesin erişebileceği büyük likiditeye sahip havuzlar, herkesin ödünç alıp verebileceği borç verme protokolleri, herkes tarafından çağrılabilen kahinler ve tüm bu nesnelerin bileşimi ve etkileşimi aynı anda gerçekleşir.  Böyle bir ekosistemi paralelleştirmek, DLT'lerin kutsal kâsesidir ve Sui'nin girişimi, uygulama katmanına çok fazla dağınıklık getirmesi dışında iyi sonuç verir.  Sorunlardan bazılarının potansiyel olarak daha iyi araç ve dil desteğiyle çözülebileceği doğru olsa da (   ), bazıları büyük VM değişiklikleri olmadan onarılamaz (   ). 1 Nesne İlkel, çok Genel, 4 Garip Paylaşılan Durum Programlaması 2 Dinamik Gönderim Yok, 3 Garip Posta Kutusu Deseni

Buy XRD with card or bank transfer via Switchere.

Bu ses hikayenin orijinal dilinde üretilmiştir!

Sui'nin MoveVM'si: Kapsamlı Bir İnceleme

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Kazanmak için Dokun: Telegram, Solana'dan Önce Sonraki 10 Milyar Kripto Kullanıcısına Katılabilir

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

AI/ML Datalake için Referans Mimarisi Oluşturmaya Yönelik Mimar Kılavuzu

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Kazanmak için Dokun: Telegram, Solana'dan Önce Sonraki 10 Milyar Kripto Kullanıcısına Katılabilir

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

AI/ML Datalake için Referans Mimarisi Oluşturmaya Yönelik Mimar Kılavuzu

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps