Yazan: Shew & Faust, geek web3

Danışman: CryptoNerdCn, Starknet ekosisteminin çekirdek geliştiricisi, tarayıcı tarafı Kahire geliştirme platformu WASM Kahire'nin kurucusu

Özet:

Starknet'in ana teknik özellikleri arasında ZK kanıtı oluşturmayı kolaylaştıran Kahire dili, yerel düzeyde AA ve iş mantığından ve durum depolamasından bağımsız akıllı sözleşme modelleri yer alır.

Kahire, Starknet'te akıllı sözleşmeleri uygulamak veya daha geleneksel uygulamalar geliştirmek için kullanılabilecek evrensel bir ZK dilidir.Sierra, derleme sürecinde bir ara dil olarak tanıtılarak, Kahire'nin alt katmanı değiştirmeye gerek kalmadan sık sık yinelenmesine olanak tanır. yalnızca değişiklikleri ara dile iletmesi gerekir; Kahire'nin standart kütüphanesi aynı zamanda hesap soyutlaması için gereken birçok temel veri yapısını da içerir.

Starknet akıllı sözleşmeleri, iş mantığını ve durum verilerini ayrı ayrı saklar. EVM zincirinden farklı olarak, Kahire sözleşme dağıtımı, "derleme, bildirim ve dağıtım" olmak üzere üç aşamayı içerir. İş mantığı, Sözleşme sınıfında ve durumu içeren Sözleşme örneğinde bildirilir. veriler bir ilişki kurma sınıfıyla birleştirilebilir ve ikincisinde yer alan kodu çağırabilir;

Starknet'in yukarıda bahsedilen akıllı sözleşme modeli, kodun yeniden kullanımı, sözleşme durumunun yeniden kullanımı, depolama katmanlaştırması ve önemsiz sözleşmelerin tespitine, aynı zamanda depolama kiralama ve işlem paralelleştirmesinin gerçekleştirilmesine de yardımcı olur. Son ikisi henüz hayata geçirilmemiş olsa da Kahire akıllı sözleşmelerinin yapısı onlar için "gerekli koşulları" yarattı.

Starknet zincirinde sadece akıllı sözleşme hesapları mevcut olup, EOA hesapları bulunmamaktadır.Native seviyede AA hesap soyutlamasını baştan itibaren destekler. AA çözümü, ERC-4337'nin fikirlerini bir dereceye kadar özümseyerek kullanıcıların son derece özelleştirilmiş işlem işleme çözümleri seçmesine olanak tanır. Starknet, olası saldırı senaryolarını önlemek amacıyla birçok karşı önlem aldı ve AA ekosisteminde önemli keşifler yaptı.

Metin: Starknet'in token ihraç etmesinin ardından STRK, Ethereum gözlemcilerinin gözünde giderek vazgeçilmez unsurlardan biri haline geldi. Her zaman "başına buyruk" olması ve "kullanıcı deneyimine önem vermemesi" ile tanınan bu Ethereum Layer 2 yıldızı, dünyadan uzakta yaşayan ve EVM'nin bulunduğu Layer 2 ekosisteminde sessizce kendi nişini yaratan bir keşiş gibidir. uyumluluk yaygındır.

Metin: Starknet'in token ihraç etmesinin ardından STRK, Ethereum gözlemcilerinin gözünde giderek vazgeçilmez unsurlardan biri haline geldi. Her zaman "başına buyruk" olması ve "kullanıcı deneyimine önem vermemesi" ile tanınan bu Ethereum Layer 2 yıldızı, dünyadan uzakta yaşayan ve EVM'nin bulunduğu Layer 2 ekosisteminde sessizce kendi nişini yaratan bir keşiş gibidir. uyumluluk yaygındır.

Starknet, kullanıcıları çok fazla görmezden geldiği ve hatta Discord'da halka açık bir "elektronik dilenci" kanalı açtığı için bir zamanlar Lu Mao Partisi tarafından eleştirilmişti. "İnsanlık dışı" olarak eleştirilirken, derin teknik kazanımları bir anda "değersiz" hale geldi. Görünüşe göre yalnızca UX ve zenginlik yaratma etkisi her şey. "Altın Köşk Tapınağı"ndaki "Başkaları tarafından anlaşılmamak tek gururum oldu" ifadesi Starknet'in otoportresinden başka bir şey değildir.

Ancak tamamen kod meraklılarının "teknik zevkine" dayanan bu önemsiz konuları bir kenara bırakırsak, Starknet ve ZK Rollup'ın öncülerinden StarkEx, Kahire meraklılarının gözünde adeta bir hazinedir. geliştiriciler, Starknet ve Cairo web3'ün her şeyidir ve ne Solidity ne de Move onlarla karşılaştırılamaz. Günümüzde "teknik meraklıları" ile "kullanıcılar" arasındaki en büyük kuşak farkı aslında daha çok insanların Starknet konusundaki farkındalık eksikliğinden kaynaklanmaktadır.

Blockchain teknolojisinin yanı sıra Starknet'in değer keşfini keşfetmeye ilgi ve istek duyan bu makalenin yazarı, Starknet'in akıllı sözleşme modeli ve yerel AA'sından başlıyor ve teknik çözümlerini ve mekanizma tasarımını kısaca sıralıyor ve daha fazla kişiye gösteriyor Starknet'in teknik özelliklerini keşfederken aynı zamanda insanların bu "başkaları tarafından anlaşılmayan yalnız korucuyu" anlamasını da umuyoruz.

Kahire dili minimalist bilimin yaygınlaştırılması

Aşağıda Starknet'in akıllı sözleşme modeline ve yerel hesap soyutlamasına odaklanacağız ve Starknet'in yerel AA'yı nasıl uyguladığını açıklayacağız. Bu makaleyi okuduktan sonra herkes Starknet'teki farklı cüzdanların anımsatıcı ifadelerinin neden karıştırılamayacağını da anlayabilir.

Ancak yerel hesap soyutlamasına geçmeden önce Starknet'in orijinal Kahire dilini anlayalım. Kahire'nin gelişimi sırasında, Cairo0 adında ilk bir versiyon ve daha sonra modern bir versiyon vardı. Cairo'nun modern versiyonunun genel sözdizimi Rust'a benzer.Aslında genel bir ZK dilidir.Starknet üzerinde akıllı sözleşmeler yazmanın yanı sıra genel uygulamaların geliştirilmesi için de kullanılabilir.

Örneğin ZK kimlik doğrulama sistemini geliştirmek için Kahire dilini kullanabiliriz.Bu program StarkNet ağına güvenmeden kurduğumuz sunucu üzerinde çalıştırılabilir. Doğrulanabilir hesaplama özellikleri gerektiren herhangi bir programın Kahire dilinde uygulanabileceği söylenebilir. Kahire şu anda ZK kanıtları oluşturmak için en elverişli programlama dili olabilir.

Derleme süreci açısından bakıldığında Kahire, aşağıdaki şekilde gösterildiği gibi orta düzey dil tabanlı bir derleme yöntemi kullanıyor. Resimdeki Sierra, Kahire dili derleme sürecindeki bir ara formdur (IR) ve Sierra, doğrudan Starknet düğüm cihazında çalışan CASM adlı daha düşük seviyeli bir ikili kod formuna derlenecektir.

Sierra'yı bir ara form olarak tanıtmak, Kahire dilinin yeni özellikler eklemesini kolaylaştırır. Çoğu durumda, temel CASM kodunu doğrudan değiştirmeden yalnızca Sierra ara dilini değiştirmeniz gerekir. Bu, birçok sorundan tasarruf sağlar ve Starknet düğümü istemcinin sık sık Güncelleme yapmasına gerek yoktur. Bu şekilde, StarkNet'in temel mantığını değiştirmeden Kahire dilinin sık sık yinelenmesi sağlanabilir. Kahire'nin standart kütüphanesi aynı zamanda hesap soyutlaması için gereken birçok temel veri yapısını da içerir.

Kahire'nin diğer yenilikleri arasında, Kahire'yi farklı donanım cihazlarına uyum sağlayabilecek düşük seviyeli makine kodu halinde derlemeyi planlayan Cairo Native adlı teorik bir çözüm yer alıyor. Starknet düğümleri, akıllı sözleşmeleri çalıştırırken KahireVM sanal makinesine güvenmek zorunda kalmayacak. Kod yürütme hızını büyük ölçüde artırın [hala teorik aşamadadır ve henüz uygulanmamıştır].

Starknet akıllı sözleşme modeli: kod mantığı ile durum depolamanın ayrılması

Starknet, EVM uyumlu zincirlerden farklı olarak akıllı sözleşme sistemlerinin tasarımında çığır açan yeniliklere sahip olup, bu yenilikler büyük ölçüde gelecekte devreye girecek yerli AA ve paralel işlem fonksiyonlarına yönelik olarak hazırlanmıştır. Burada, Ethereum gibi geleneksel halka açık zincirlerde akıllı sözleşmelerin dağıtımının genellikle "derleme sonrası dağıtım" yöntemini takip ettiğini bilmemiz gerekiyor. Örnek olarak ETH akıllı sözleşmesini ele alalım:

1. Geliştiriciler akıllı sözleşmeleri yerel olarak yazdıktan sonra, Solidity programını editör aracılığıyla EVM bayt koduna derlerler, böylece EVM tarafından doğrudan anlaşılıp işlenebilir;

2. Geliştirici, akıllı sözleşmeyi dağıtmak için bir işlem isteği başlatır ve derlenmiş EVM bayt kodunu Ethereum zincirine dağıtır.

(Resim kaynağı: not-satoshi.com)

Her ne kadar Starknet'in akıllı sözleşmeleri de "önce derle, sonra dağıt" fikrini izlese de, akıllı sözleşmeler zincir üzerinde CairoVM tarafından desteklenen CASM bayt kodu biçiminde konuşlandırılır. Ancak akıllının çağırma yöntemi ve durum depolama modu açısından Sözleşmeler, Starknet EVM zincirleriyle uyumlu değil, çok büyük bir fark var.

Kesin olarak söylemek gerekirse, Ethereum akıllı sözleşmesi = iş mantığı + durum bilgisi. Örneğin, USDT sözleşmesi yalnızca Transfer ve Onay gibi ortak işlevleri uygulamakla kalmaz, aynı zamanda tüm USDT sahiplerinin varlık durumunu da saklar. Kod ve durum Birlikte birleştirilir. Bu çok fazla sorun getiriyor. Öncelikle, DAPP sözleşme yükseltmesine ve durum geçişine elverişli değildir ve aynı zamanda işlemlerin paralel olarak işlenmesine de elverişli değildir. Ağır bir teknik yüktür.

Kesin olarak söylemek gerekirse, Ethereum akıllı sözleşmesi = iş mantığı + durum bilgisi. Örneğin, USDT sözleşmesi yalnızca Transfer ve Onay gibi ortak işlevleri uygulamakla kalmaz, aynı zamanda tüm USDT sahiplerinin varlık durumunu da saklar. Kod ve durum Birlikte birleştirilir. Bu çok fazla sorun getiriyor. Öncelikle, DAPP sözleşme yükseltmesine ve durum geçişine elverişli değildir ve aynı zamanda işlemlerin paralel olarak işlenmesine de elverişli değildir. Ağır bir teknik yüktür.

Bu bağlamda Starknet durum depolama yöntemini geliştirmiştir.Akıllı sözleşme uygulama planında DAPP'ın iş mantığı varlık durumundan tamamen ayrıştırılarak farklı yerlerde saklanmaktadır.Bunun faydaları ortadadır.Öncelikle, sistem daha verimli.Yinelenen veya yedekli kod dağıtımlarının olup olmadığını hızla belirleyin. Buradaki prensip şudur:

Ethereum'un akıllı sözleşmesi = iş mantığı + durum verileri.Tam olarak aynı iş mantığına sahip ancak farklı durum verilerine sahip birkaç sözleşme varsa, o zaman bu sözleşmelerin karmaları da farklı olacaktır.Şu anda sistemin bunları ayırt etmesi zordur. bu sözleşmelerin gereksiz olup olmadığı, "çöp sözleşme" olup olmadığı.

Starknet'in çözümünde kod kısmı ve durum verileri doğrudan ayrılıyor.Kod kısmının hash'ine bağlı olarak sistem, hash'leri aynı olduğundan aynı kodun birden çok kez konuşlandırılıp dağıtılmadığını daha kolay anlayabilir. Bu, tekrarlanan kod dağıtım davranışının önlenmesini kolaylaştırır ve Starknet düğümlerinde depolama alanından tasarruf sağlar.

Starknet'in akıllı sözleşme sisteminde sözleşmelerin dağıtımı ve kullanımı üç aşamaya ayrılmıştır: "derleme, bildirim ve dağıtım". Bir varlık ihraççısı Kahire sözleşmesini dağıtmak istiyorsa ilk adım, yazılı Kahire kodunu yerel olarak kendi cihazında Sierra'ya ve temel bayt kodu CASM formuna derlemektir.

Daha sonra, sözleşme dağıtıcısı bir "bildirme" işlemi yayınlar ve sözleşmenin CASM bayt kodunu ve Sierra ara kodunu Sözleşme Sınıfı adı verilen zincire dağıtır.

(Resim kaynağı: Starknet resmi web sitesi)

Daha sonra, varlık sözleşmesinde tanımlanan işlevleri kullanmak istiyorsanız, DAPP ön ucu aracılığıyla bir "dağıtım" işlemi başlatabilir ve Sözleşme Sınıfıyla ilişkili bir Sözleşme örneğini dağıtabilirsiniz. Bu örnek, varlık durumunu depolayacaktır. Bundan sonra kullanıcı, Sözleşme örneğinin durumunu değiştirmek için Sözleşme Sınıfındaki işlev işlevini çağırabilir.

Aslında nesne yönelimli programlamayı anlayan herkes, Sınıf ve Örneğin Starknet'te neyi temsil ettiğini kolayca anlayabilmelidir. Geliştiricinin bildirdiği Sözleşme Sınıfı sadece akıllı sözleşmenin iş mantığını içerir.Herkesin çağırabileceği bir fonksiyondur.Ancak gerçek varlık statüsüne sahip değildir bu nedenle doğrudan "varlık varlığı"nı uygulamaz. sadece "ruhu" vardır, "bedeni" yoktur.

Kullanıcı belirli bir Sözleşme örneğini dağıttığında varlık "gerçekleştirilir". Eğer varlığın "varlık" durumunu değiştirmek istiyorsanız, örneğin tokenınızı başka birine devretmek istiyorsanız, doğrudan Sözleşme Sınıfında yazılı fonksiyonu çağırabilirsiniz. Yukarıdaki süreç, geleneksel nesne yönelimli programlama dillerindeki "örneklemeye" biraz benzer (ancak tam olarak aynısı değildir).

Akıllı sözleşmeler sınıflara ve örneklere ayrıldıktan sonra iş mantığı ve durum verileri ayrıştırılarak Starknet'e aşağıdaki özellikler getirilir:

1. Depolama katmanlamanın ve "depo kiralama sisteminin" gerçekleştirilmesine yardımcı olur

Depolama katmanlaması olarak adlandırılan şey, geliştiricilerin verileri Starknet zinciri gibi kendi ihtiyaçlarına göre özelleştirilmiş konumlara yerleştirebilecekleri anlamına gelir. StarkNet, Celestia gibi DA katmanlarıyla uyumlu olmaya hazırdır ve DAPP geliştiricileri verileri bu üçüncü taraf DA katmanlarında saklayabilir. Örneğin bir oyun, en önemli varlık verilerini Starknet ana ağında saklayabilir ve diğer verileri Celestia gibi zincir dışı DA katmanlarında saklayabilir. DA katmanını güvenlik gereksinimlerine göre özelleştirmeye yönelik bu çözüme Starknet tarafından "Volition" adı verildi.

Depolama kiralama sistemi olarak adlandırılan sistem, herkesin işgal ettiği depolama alanı için ödeme yapmaya devam etmesi gerektiği anlamına gelir. Zincirde ne kadar yer kaplarsanız teorik olarak kira ödemeye devam etmelisiniz.

Ethereum akıllı sözleşme modelinde, sözleşmenin mülkiyeti belirsizdir ve bir ERC-20 sözleşmesi için "kira"yı dağıtıcının mı yoksa varlık sahibinin mi ödemesi gerektiğini ayırt etmek zordur. uzun bir süredir ve yalnızca sözleşme dağıtıldığında ödenir. Dağıtıcılardan bir ücret alınır ve bu, makul bir depolama ücreti modeli değildir.

Starknet, Sui, CKB ve Solana'nın akıllı sözleşme modelleri kapsamında, akıllı sözleşmelerin mülkiyeti daha net bir şekilde bölünmüş olup, depolama fonlarının toplanması daha kolay hale gelmektedir [Şu anda Starknet doğrudan bir depolama kiralama sistemi başlatmıyor ancak uygulanacaktır. gelecekte]

2. Kodun gerçek anlamda yeniden kullanımını sağlayın ve gereksiz sözleşmelerin dağıtımını azaltın

Bir sınıf olarak zincirde depolanacak genel bir token sözleşmesi ilan edebiliriz ve ardından herkes kendi token örneklerini dağıtmak için bu sınıftaki işlevleri çağırabilir. Dahası, sözleşme aynı zamanda doğrudan sınıftaki kodu çağırabilir ve bu da Solidity'deki Kütüphane fonksiyon kütüphanesine benzer bir etki sağlar.

Starknet'in akıllı sözleşme modeli aynı zamanda "önemsiz sözleşmelerin" belirlenmesine de yardımcı oluyor. Bu daha önce açıklanmıştı. Kodun yeniden kullanımını ve önemsiz sözleşme tespitini destekledikten sonra Starknet, zincirdeki veri miktarını önemli ölçüde azaltabilir ve düğümler üzerindeki depolama baskısını mümkün olduğunca azaltabilir.

3. Gerçek sözleşme “durumunun” yeniden kullanılması

Blockchain üzerindeki sözleşme yükseltmeleri esas olarak iş mantığındaki değişiklikleri içerir.Starknet senaryosunda, akıllı sözleşmelerin iş mantığı ve varlık durumu doğası gereği ayrılmıştır.Sözleşme örneği ilgili sözleşme türü sınıfını değiştirirse, iş mantığı yükseltmesi tamamlanabilir. , Varlık durumunu yeni bir yere taşımaya gerek yoktur.Bu sözleşme yükseltme biçimi, Ethereum'unkinden daha kapsamlı ve yereldir.

Bir Ethereum sözleşmesinin iş mantığını değiştirmek için genellikle iş mantığını bir acente sözleşmesine "dış kaynaklardan sağlamak" ve bağımlı acentelik sözleşmesini değiştirerek ana sözleşmenin iş mantığını değiştirmek gerekir.Ancak bu yöntem yeterince basit değildir. ve "yerli değil".

(Resim kaynağı: wtf Academy)

Bazı senaryolarda, eski Ethereum sözleşmesi tamamen terk edilirse, içerideki varlık durumu doğrudan yeni konuma taşınamaz ki bu da çok zahmetlidir.Ancak, Kahire sözleşmesinin durumu taşımasına gerek yoktur ve durumu doğrudan "yeniden kullanabilir". eski durum.

4. İşlemlerin paralel işlenmesine olanak sağlar

Bazı senaryolarda, eski Ethereum sözleşmesi tamamen terk edilirse, içerideki varlık durumu doğrudan yeni konuma taşınamaz ki bu da çok zahmetlidir.Ancak, Kahire sözleşmesinin durumu taşımasına gerek yoktur ve durumu doğrudan "yeniden kullanabilir". eski durum.

4. İşlemlerin paralel işlenmesine olanak sağlar

Farklı alım satım talimatlarının paralelliğini en üst düzeye çıkarmak için gerekli bir adım, Bitcoin, CKB ve Sui'de görülebileceği gibi farklı kişilerin varlık durumlarını ayrı konumlarda saklamaktır. Yukarıdaki hedefin ön koşulu, akıllı sözleşmelerin iş mantığını varlık durumu verilerinden ayırmaktır. Starknet, işlem paralelliğinin derinlemesine teknik uygulamasını henüz uygulamamış olsa da, paralel işlemler gelecekte önemli bir hedef olacaktır.

Starknet'in yerel AA ve hesap sözleşmesi dağıtımı

Aslında hesap soyutlaması ve AA olarak adlandırılan kavramlar, Ethereum topluluğu tarafından icat edilen benzersiz kavramlardır.Birçok yeni halka açık zincirde, EOA hesapları ile akıllı sözleşme hesapları arasında bir ayrım yapılmamış ve Ethereum tarzı hesap sisteminden kaçınılmıştır. başlangıç. çukur. Örneğin, Ethereum ayarında, EOA hesap denetleyicisinin bir işlemi başlatabilmesi için zincirde ETH'ye sahip olması gerekir.Çeşitli kimlik doğrulama yöntemlerini doğrudan seçmenin bir yolu yoktur ve bazı özelleştirilmiş ödeme mantığını eklemek son derece zahmetlidir. . Hatta bazı insanlar Ethereum'un hesap tasarımının tamamen insan karşıtı olduğunu düşünüyor.

Starknet veya zkSyncEra gibi "native AA" odaklı zincirlere baktığımızda bariz farklar görebiliriz: Öncelikle Starknet ve zkSyncEra birleşik hesap türlerine sahiptir, zincirde sadece akıllı sözleşme hesapları vardır ve böyle bir şey yoktur. (zkSync Era, Metamask ile uyumluluğu kolaylaştırmak için Ethereum EOA hesabının özelliklerini simüle ederek kullanıcının yeni oluşturulan hesabına varsayılan olarak bir dizi sözleşme kodu dağıtacaktır).

Starknet, Metamask gibi Ethereum çevre birimleriyle doğrudan uyumluluğu dikkate almamıştır. Kullanıcılar Starknet cüzdanını ilk kez kullandıklarında, özel bir sözleşme hesabı otomatik olarak dağıtılacaktır. Açıkça söylemek gerekirse, yukarıda belirtilen sözleşme örneğinin dağıtılmasıdır. Bu sözleşme örneği cüzdan projesiyle önceden konuşlandırılacaktır. Sözleşme sınıfıyla ilişkili olarak sınıfta yazılan bazı işlevleri doğrudan çağırabilirsiniz.

Şimdi ilginç bir konuya değineceğiz: STRK airdrop'unu alırken birçok kişi Argent ve Braavos cüzdanlarının birbiriyle uyumlu olmadığını fark etti.Argent'in anımsatıcı ifadesini Braavos'a aktardıktan sonra ilgili hesap dışa aktarılamıyor.Bunun nedeni aslında Argent'in olmasıdır. ve Braavos Farklı hesap oluşturma hesaplama yöntemleri kullanılmakta, bu da aynı anımsatıcı ifade için farklı hesap adreslerinin oluşturulmasına neden olmaktadır.

Spesifik olarak, Starknet'te yeni dağıtılan sözleşme adresi, aşağıdaki formül kullanılarak deterministik bir algoritma yoluyla elde edilebilir:

Yukarıdaki formüldeki pedersen(), ZK sisteminde kullanımı kolay bir karma algoritmasıdır. Bir hesap oluşturma işlemi aslında karşılık gelen karma değeri oluşturmak için pedersen işlevine birkaç özel parametre girmektir. Bu karma, oluşturulan hesap adresi..

Yukarıdaki resim Starknet tarafından "yeni bir sözleşme adresi" oluşturmak için kullanılan çeşitli parametreleri göstermektedir. konuşlandırma_adresi "sözleşme dağıtıcısının" adresini temsil eder. Bu parametre boş olabilir. Önceden bir Starknet sözleşme hesabınız olmasa bile, yine de yeni bir sözleşme dağıtın.

Yukarıdaki resim Starknet tarafından "yeni bir sözleşme adresi" oluşturmak için kullanılan çeşitli parametreleri göstermektedir. konuşlandırma_adresi "sözleşme dağıtıcısının" adresini temsil eder. Bu parametre boş olabilir. Önceden bir Starknet sözleşme hesabınız olmasa bile, yine de yeni bir sözleşme dağıtın.

salt, sözleşme adresinin salt değerini hesaplamak için kullanılır. Basitçe söylemek gerekirse, rastgele bir sayıdır. Bu değişken aslında sözleşme adreslerinin tekrarlanmasını önlemek için tanıtılmıştır. class_hash, daha önce tanıtıldığı gibi sözleşme örneğine karşılık gelen sınıfın karma değeridir. Vestructor_calldata_hash, sözleşme başlatma parametrelerinin karmasını temsil eder.

Yukarıdaki formüle dayanarak kullanıcılar, sözleşme zincirde dağıtılmadan önce oluşturulan sözleşme adresini önceden hesaplayabilir. Starknet, kullanıcıların önceden bir Starknet hesabına sahip olmadan sözleşmeleri doğrudan dağıtmalarına olanak tanır.Süreç aşağıdaki gibidir:

1. Kullanıcı öncelikle dağıtmak istediği sözleşme örneğini, hangi sözleşme sınıfıyla ilişkilendirmek istediğini belirler, sınıfın karmasını başlatma parametrelerinden biri olarak kullanır ve oluşturduğu sözleşme adresini bilmek için tuzu hesaplar;

2. Kullanıcı sözleşmeyi nereye dağıtacağını öğrendikten sonra öncelikle sözleşme dağıtım ücreti olarak belirli bir miktar ETH'yi adrese aktarır. Genel olarak konuşursak, ETH'nin bu kısmının zincirler arası bir köprü aracılığıyla L1'den Starknet ağına geçmesi gerekiyor;

3. Kullanıcı, sözleşme dağıtımı için bir işlem isteği başlatır.

Aslında tüm Starknet hesapları yukarıdaki süreç üzerinden konuşlandırılıyor ancak çoğu cüzdan detayları koruyor ve kullanıcılar süreci hiçbir şekilde algılayamıyor.Sanki sözleşme hesabı ETH transferinden sonra dağıtılıyor.

Yukarıdaki çözüm bazı uyumluluk sorunlarını beraberinde getirir çünkü farklı cüzdanlar hesap adresleri oluşturduğunda oluşturulan sonuçlar tutarsızdır. Yalnızca aşağıdaki koşulları karşılayan cüzdanlar karıştırılabilir:

Daha önce bahsettiğimiz olayda hem Argent hem de Braavos ECDSA imza algoritmasını kullanıyordu ancak iki tarafın tuz hesaplama yöntemleri farklıydı.İki cüzdanda aynı anımsatıcı ifadeyle oluşturulan hesap adresleri tutarsız olacaktı.

Hesap soyutlama konusuna geri dönelim. Starknet ve zkSync Era, kimlik doğrulama (dijital imzaların doğrulanması), gaz ücreti ödemesi ve diğer temel mantık gibi işlem işleme sürecinde yer alan bir dizi süreci "zincirin alt katmanı" dışında uygulanacak şekilde taşıyor. Kullanıcılar yukarıdaki mantığın uygulama detaylarını kendi hesaplarında özelleştirebilirler.

Örneğin, Starknet akıllı sözleşme hesabınıza özel bir dijital imza doğrulama işlevi dağıtabilirsiniz.Starknet düğümü sizin tarafınızdan başlatılan işlemi aldığında, zincir üstü hesabınızda özelleştirilmiş bir dizi işlem işleme mantığını çağıracaktır. Bu açıkça daha esnektir.

Ethereum'un tasarımında, kimlik doğrulama (dijital imza) gibi mantık, düğüm istemci kodunda sabit kodlanmıştır ve hesap işlevlerinin özelleştirilmesini yerel olarak destekleyemez.

(Starknet mimarı tarafından belirlenen yerel AA çözümünün şematik diyagramı. İşlem doğrulaması ve gaz ücreti yeterlilik doğrulaması, işlenmek üzere zincir üzerindeki sözleşmeye aktarılır. Zincirin temelindeki sanal makine, bu kullanıcı tanımlı veya belirtilen işlevleri çağırabilir)

zkSyncEra ve Starknet yetkililerine göre, bu hesap işlevi modülerleştirme fikirleri seti EIP-4337'ye dayanmaktadır. Ancak fark, zkSync ve Starknet'in başından beri hesap türlerini birleştirmesi, işlem türlerini birleştirmesi ve tüm işlemleri almak ve işlemek için birleşik bir giriş kullanmasıdır. Ancak Ethereum'un geçmiş bagajı vardır ve vakıf, hard forklardan mümkün olduğunca kaçınmayı umuyor Kaba bir yineleme planını beklerken, "ülkeyi eğrilerden kurtarmak" için EIP-4337 planını destekliyor. Ancak bunun etkisi, EOA hesabının ve 4337 planının her birinin garip ve şişirilmiş görünen bağımsız işlem işleme süreçlerini benimsemesidir. yerel AA'nın aksine kullanışlı.

(Resim kaynağı: ArgentWallet)

Bununla birlikte, Starknet'in yerel hesap soyutlaması henüz tam olgunluğa ulaşmamıştır. Pratik ilerlemeye bakılırsa, Starknet'in AA hesabı imza doğrulama algoritmasının özelleştirilmesini uygulamıştır. Bununla birlikte, ücret ödemesinin özelleştirilmesi için Starknet şu anda aslında yalnızca ETH'yi desteklemektedir ve STRK gas ücretlerini ödemektedir ve henüz üçüncü taraf gaz ödemesini desteklemiyor. Bu nedenle Starknet'in yerli AA konusunda kaydettiği ilerlemenin "teorik çözümün temelde olgunlaştığı, pratik çözümün ise halen ilerlemekte olduğu" söylenebilir.

Starknet'te yalnızca akıllı sözleşme hesapları bulunduğundan tüm işlem sürecinde hesap akıllı sözleşmelerinin etkisi dikkate alınır. Öncelikle Starknet düğümünün bellek havuzu (Mempool) tarafından bir işlem alındıktan sonra doğrulanması gerekir.Doğrulama adımları şunları içerir:

Burada şunu belirtelim ki, hesap akıllı sözleşmesinde özelleştirilmiş imza doğrulama fonksiyonunun kullanılması, bir saldırı senaryosunun var olduğu anlamına gelir. Çünkü hafıza havuzu yeni işlemlerin imzalarını doğrularken gas ücreti almıyor (gas ücretleri doğrudan alınırsa daha ciddi saldırı senaryolarına yol açacaktır). Kötü niyetli kullanıcılar önce hesap sözleşmelerinde süper karmaşık bir imza doğrulama işlevini özelleştirebilir ve ardından çok sayıda işlem başlatabilir.Bu işlemler doğrulandığında, düğümün gücünü doğrudan tüketebilecek özelleştirilmiş karmaşık imza doğrulama işlevini çağıracaklar. kaynaklar.

Bu durumun önüne geçmek için StarkNet işlemlere aşağıdaki kısıtlamaları getirmektedir:

Starknet işlemlerinin akış şeması aşağıdaki gibidir:

Starknet işlemlerinin akış şeması aşağıdaki gibidir:

İşlem doğrulama sürecini daha da hızlandırmak için Braavos ve Argent cüzdanlarının imza doğrulama algoritmalarının doğrudan Starknet düğüm istemcisine uygulandığını belirtmekte fayda var.Düğüm, işlemin bu iki ana Starknet cüzdanından üretildiğini keşfettiğinde, istemcideki yerleşik algoritmayı çağıracaktır.Braavos/Argent imza algoritması, bu önbelleğe alma benzeri fikir aracılığıyla Starknet, işlem doğrulama süresini kısaltabilir.

İşlem verileri, sıralayıcının doğrulamasını geçtikten sonra (sıralayıcının doğrulama adımları, bellek havuzu doğrulamasından çok daha derindir), sıralayıcı, işlemleri bellek havuzundan paketleyecek ve bunları ZK sertifika oluşturucusuna gönderecektir. Bu linke girilen işlem başarısız olsa bile gaz ücreti tahsil edilecektir.

Ancak okuyucular Starknet'in geçmişini anlarlarsa, eski Starknet'in başarısız işlemler için işlem ücreti talep etmediğini göreceklerdir.En yaygın işlem başarısızlığı durumu, kullanıcının yalnızca 1 ETH'ye sahip olması ancak 10 ETH aktarmasıdır. İşlemin açıkça bir mantığı vardır. Hatalar eninde sonunda başarısızlığa uğrayacaktır, ancak yürütülene kadar hiç kimse sonucun ne olacağını bilemez.

Ancak StarkNet geçmişte bu tür başarısız işlemler için ücret talep etmemişti. Bu maliyetsiz hatalı işlem, Starknet düğümlerinin bilgi işlem kaynaklarını boşa harcayacak ve DDoS saldırı senaryolarına yol açacaktır. İlk bakışta hatalı işlemler için ücret alınmasının uygulanması kolay gibi görünse de aslında oldukça karmaşıktır. Starknet, büyük ölçüde başarısız işlemler için gaz toplama sorununu çözmek amacıyla Kahire1 dilinin yeni bir versiyonunu başlattı.

ZK Proof'un bir geçerlilik kanıtı olduğunu ve başarısız bir işlemin sonucunun geçersiz olduğunu ve zincirde bir çıktı sonucu bırakamayacağını hepimiz biliyoruz. Belirli bir talimatın geçersiz olduğunu ve bir çıktı sonucu üretemeyeceğini kanıtlamak için geçerlilik kanıtını kullanmaya çalışmak oldukça garip gelebilir ancak aslında mümkün değildir. Bu nedenle geçmişte Starknet kanıt oluşturduğunda, çıktı sonucu üretemeyen tüm başarısız işlemleri doğrudan ortadan kaldırıyordu.

Starknet ekibi daha sonra daha akıllı bir çözümü benimsedi ve yeni bir sözleşme dili olan Cairo1'i geliştirdi, böylece "tüm işlem talimatları çıktı sonuçları üretebilir ve zincir üzerinde olabilir." İlk bakışta, tüm işlemler çıktı üretebilir, bu da hiçbir zaman mantıksal hata olmadığı anlamına gelir.Çoğu zaman işlemler, talimatların yürütülmesini kesintiye uğratan bazı hatalarla karşılaşıldığından başarısız olur.

Hiçbir zaman kesintiye uğramayan ve başarılı bir şekilde çıktı üreten bir işlemi başarmak zordur ancak aslında çok basit bir alternatif var o da işlemin bir mantık hatasıyla karşılaşıp kesintiye neden olduğu durumlarda çıktı sonuçları üretmesini sağlamak, ancak bu sefer A False değeri döndürecek olursa herkesin işlemin sorunsuz bir şekilde yürütülmediğini bilmesini sağlar.

Ancak şunu da belirtmek gerekir ki False değeri döndürmek aynı zamanda çıktı sonucunu da döndürmektedir.Yani Kahire1'de talimatın bir mantık hatasıyla karşılaşması ya da geçici bir kesinti olması fark etmez, çıktı sonucu oluşturulup zincir üzerinde oluşturulabilmektedir. Bu çıktı doğru olabileceği gibi Yanlış hata mesajı da olabilir.

Örneğin, aşağıdaki kod segmenti varsa

Buradaki _balances::read(from) - miktar, taşma nedeniyle bir hata bildirebilir.Bu sırada ilgili işlem talimatı kesintiye uğrayacak ve yürütülmesi durdurulacak ve işlem sonucu zincirde bırakılmayacaktır; yeniden yazıldı Aşağıdaki formda, bir işlem başarısız olduğunda, bir çıktı sonucu yine de döndürülür ve zincirde kalır.Tamamen görsel açıdan bakıldığında, sanki tüm işlemler başarıyla zincirdeki işlem çıktısını bırakabiliyormuş gibi ve özeldir birleşik bir işlem ücreti talep etmek. Makul.

StarknetAA Sözleşmesine Genel Bakış

Bu makalenin bazı okuyucularının programlama geçmişine sahip olabileceğini göz önünde bulundurarak, Starknet'teki hesap özeti sözleşmesinin arayüzünün kısa bir gösterimini burada bulabilirsiniz:

Yukarıdaki arayüzdeki __validate_declare__ kullanıcı tarafından başlatılan bildirim işlemini doğrulamak için kullanılırken __validate__ genel işlemi doğrulamak için, esas olarak kullanıcının imzasının doğru olup olmadığını doğrulamak için kullanılır ve __execute__ işlemi yürütmek için kullanılır. Starknet sözleşmeli hesapların varsayılan olarak çoklu çağrıyı desteklediğini görebiliriz. Birden fazla çağrı, belirli DeFi etkileşimlerini gerçekleştirirken aşağıdaki üç işlemi paketlemek gibi çok ilginç bazı işlevler gerçekleştirebilir:

Elbette birden fazla çağrı atomik olduğundan, belirli arbitraj işlemlerinin gerçekleştirilmesi gibi daha karmaşık kullanımlar da vardır.

Özetle

Starknet'in ana teknik özellikleri arasında ZK kanıtı oluşturmayı kolaylaştıran Kahire dili, yerel düzeyde AA ve iş mantığından ve durum depolamasından bağımsız akıllı sözleşme modelleri yer alır.

Kahire, Starknet'te akıllı sözleşmeleri uygulamak veya daha geleneksel uygulamalar geliştirmek için kullanılabilecek evrensel bir ZK dilidir.Sierra, derleme sürecinde bir ara dil olarak tanıtılarak, Kahire'nin alt katmanı değiştirmeye gerek kalmadan sık sık yinelenmesine olanak tanır. yalnızca değişiklikleri ara dile iletmesi gerekir; Kahire'nin standart kütüphanesi aynı zamanda hesap soyutlaması için gereken birçok temel veri yapısını da içerir.

Starknet akıllı sözleşmeleri, iş mantığını ve durum verilerini ayrı ayrı saklar. EVM zincirinden farklı olarak, Kahire sözleşme dağıtımı, "derleme, bildirim ve dağıtım" olmak üzere üç aşamayı içerir. İş mantığı, Sözleşme sınıfında ve durumu içeren Sözleşme örneğinde bildirilir. veriler bir ilişki kurma sınıfıyla birleştirilebilir ve ikincisinde yer alan kodu çağırabilir;

Starknet'in yukarıda bahsedilen akıllı sözleşme modeli, kodun yeniden kullanımı, sözleşme durumunun yeniden kullanımı, depolama katmanlaştırması ve önemsiz sözleşmelerin tespitine, aynı zamanda depolama kiralama ve işlem paralelleştirmesinin gerçekleştirilmesine de yardımcı olur. Son ikisi henüz hayata geçirilmemiş olsa da Kahire akıllı sözleşmelerinin yapısı onlar için "gerekli koşulları" yarattı.

Starknet'in yukarıda bahsedilen akıllı sözleşme modeli, kodun yeniden kullanımı, sözleşme durumunun yeniden kullanımı, depolama katmanlaştırması ve önemsiz sözleşmelerin tespitine, aynı zamanda depolama kiralama ve işlem paralelleştirmesinin gerçekleştirilmesine de yardımcı olur. Son ikisi henüz hayata geçirilmemiş olsa da Kahire akıllı sözleşmelerinin yapısı onlar için "gerekli koşulları" yarattı.

Starknet zincirinde sadece akıllı sözleşme hesapları mevcut olup, EOA hesapları bulunmamaktadır.Native seviyede AA hesap soyutlamasını baştan itibaren destekler. AA çözümü, ERC-4337'nin fikirlerini bir dereceye kadar özümseyerek kullanıcıların son derece özelleştirilmiş işlem işleme çözümleri seçmesine olanak tanır. Starknet, olası saldırı senaryolarını önlemek amacıyla birçok karşı önlem aldı ve AA ekosisteminde önemli keşifler yaptı.