Ethereum'un evrimi: ETH2.0 mühendislik kılavuzu
PowerPoint'te bu ilginç resmi yaptığı için Nic Carter'a özel teşekkürler
Ethereum 2.0 hakkında
Ethereum 2.0, Ethereum'a planlanan alternatiftir. Önümüzdeki birkaç yıl içinde, Ethereum 2.0 tasarımcıları, fikir birliği sistemini ve Ethereum durumunu tamamen dahil etmeyi planlıyor. Ethereum 2.0'ın kapsamı çok geniş olduğu için, neyi içereceğini veya neyi içermeyeceğini tam olarak söyleyemeyiz. Ethereum 2.0 hakkında bazı spesifikasyonlarımız var ve pek çok ekip geliştirmenin erken uygulanması için çalışıyor. Şu anda Ethereum 2.0 tasarımcıları tarafından planlanan tasarım, parçalama, Casper, devlet kiralaması ve eWASM sanal makinesini içeriyor. Ön müşteri testleri devam ediyor ve geliştiricilerin üç ay içinde hafif bir Ethereum 2.0 testnet başlatması bekleniyor (Q12019). İlk başta, Ethereum 2.0, Ethereum ana zincirinden Ether alacak, ancak tasarımcı nihayet Ethereum 2.0'ı ana zincir ve Ethereum 1.X'i kendi yönetimi altındaki parça zinciri olarak yapmayı planlıyor.
Bu mühendisler için ne anlama geliyor?
Bir Solidity veya Dapp geliştiricisiyseniz ve Ethereum 2.0 akıllı sözleşmeleri kullanmak istiyorsanız, o zaman çok şey öğrenmeniz gerekecek. Ethereum 2.0, Ethereum'un yerini tamamen alıyor ve akıllı sözleşmeler yazarken yaptığımız birçok varsayımı değiştirecek. Ethereum 2.0'ın planlanan çok aşamalı lansmanında güncelleme, yükseltme döngüsü değil, ürün sürüm döngüsüdür. Ethereum 1.X için yazdığımız araçlar ve akıllı sözleşmelerin Ethereum 2.0 için yeniden tasarlanması ve yeniden yazılması gerekebilir. Neyse ki, ekosistemi hazırlamak için birkaç yılımız var. Bu hedefe ulaşmanıza yardımcı olmak için, mevcut yol haritasını tartışmak ve bazı mühendislik etkilerini tanıtmak istiyorum.Aşamalar halinde kullanıma sunun
Şu anda, parçalama yol haritası (Ethereum 2.0 yol haritasının iki katı) yedi aşama listeliyor. Bunlar arasında yalnızca Aşama 0 (Aşama 0) önemli bir spesifikasyona sahiptir ve düzenli olarak güncellenecektir. Aşama 1 (Aşama 1) özelliği, doğruluk açısından çok daha düşüktür ve aktif olarak geliştirilmediği görülmektedir. İlk aşamadan sonra yol haritası, teknik belgeler yerine bir hedefler listesi haline gelir. Örneğin, 2. Aşamada (2. Aşama), ethreaser.ch'ye giden yol haritası bağlantılarının sayısı, github bağlantısının üç katı olacaktır. Daha fazla tartışma mühendislikten ziyade spekülasyon gibi göründüğünden, özel tartışmamız Aşama 0, Aşama 1 ve Aşama 2 ile sınırlıdır ve gelecekteki olası yönlerin bazı kaba genel bakışlarını dahil ettik.
Aşağıda her aşamanın geliştirme durumunu tanıtacağız.
Faz 0-İşaretçi Zinciri
Aşama 0, "işaret zinciri" ni sunar. Ethereum 2.0 tasarımcıları, işaret zincirini Ethereum 2.0 ekosisteminin merkezi yapmayı ve diğer tüm parçalar için güvenlik ve doğrulama kaynağı olmayı umuyor. İşaret zinciri açıldığında, Casper FFG'nin PoS mekanizmasını çalıştıracaktır. İşaret zincirinin erken yinelemeleri olabildiğince basit olacak şekilde tasarlanmıştır, bu nedenle aşama 0 akıllı sözleşmeleri, hesapları, varlık transferlerini desteklemez ve herhangi bir parça içermez. İşaret zincirindeki eter zincir üzerinde aktarılamaz, bu da kullanıcıların bunu borsaya yatıramayacağı anlamına gelir.
BETH: yeni eter
Beacon ETH (BETH), işaretçi zincirinde doğrulayıcı tarafından kullanılan tek yeni varlıktır. İki şekilde oluşturulur: 1) işaret zincirini (ve 1. aşamadan sonraki parçaları) doğrulamanın bir ödülü olarak, 2 ) Herhangi bir Ethereum 1.x kullanıcısı, Ethereum 1.x sözleşmesi aracılığıyla BETH satın alabilir. Kontrat buna "marj" diyor. Mühendis, sözleşmenin iptal işlevinin olmadığını fark edebilir. Bunun nedeni, aşama 0'da BETH'i işaret zincirinden çekemeyeceğimizdir. Başka bir deyişle, Ethereum 1.x doğrulayıcı kayıt sözleşmesinde depolandığında, Ethereum 1.x etkin bir şekilde yakılacaktır. İşaret zinciri doğrulayıcı, sözleşmeyi kontrol eder ve para yatırma bilgilerini işaret zincirine gönderir ve işaret zinciri, yatırıcıya yeni BETH verir. Bu nedenle, amacımız şudur: Para yatıran, sözleşmeyi kaydetmek için doğrulayıcıya Ether gönderdikten hemen sonra, işaret zinciri tarafından verilen ilgili BETH miktarını alacaktır. Depozitoların geçici olarak gözden geçirilmesi mümkündür, ancak Casper'ın kurallarına göre, kalıcı bir inceleme yapılması olası değildir.İşaret zinciri üzerindeki Ether'in aktarımı 2. Aşamaya (ikinci aşama) kadar beklemelidir.Ethereum 1.X tamamen parçalama ekosistemine katlanmadan önce BETH'i Ethereum'a geri götürmenin bir yolu olmayacağına inanıyorum. 1.X. Aşama 0'ın eksik olduğu ve güvenilir bir Aşama 1 belirtimi olmadığı göz önüne alındığında, BETH'in bağımsız ve devredilemez bir varlık olarak en az 2 yıl süreceğini makul bir şekilde varsayabiliriz. Aşama 2 tamamlandığında, BETH parçaya veya parçadan aktarılabilecektir; ancak, Ether olmayacaktır. Bunun ciddi ekonomik zorluklara neden olması olası değildir.
Geçmişte, birçok borsa, BETH benzeri tokenleri IOU (IOU) aracılığıyla önceden işlem görüyordu. Örneğin, Tezos kitle fonlaması döneminde Hitbit ve BitMEX borsaları ilgili vadeli işlem piyasalarını başlattı. Piyasanın BETH için bir alım satım talebi varsa, bazı borsaların BETH saklama alım satımını ve yatırımını destekleyeceğini görebiliriz. Ancak, piyasanın BETH talebinde bazı sorunlar var gibi görünüyor. ETH ve BETH arasındaki tek yönlü 1: 1 bağlantı nedeniyle, BETH'in maksimum fiyatı vardır ve bu iyi bir yatırım hedefi değildir. Başka bir deyişle, BETH'nin değeri asla Ether'i geçemez ve Ether'den daha düşük olabilir.
Aşama 0 + -Paylaşma
Kullanıcılar işaret zincirine 32 BETH yatırabilir ve ardından doğrulayıcı olabilir. Aşama 0'da, doğrulayıcı yalnızca işaret zincirini yönetecektir. Doğrulayıcı, ilk aşamadan başlayarak 1024 parça zincirini de yönetecek. İşaret zinciri (ve her bir parça zinciri), blokları belirlemek için Casper FFG mekanizmasını kullanacaktır. Casper FFG, zincir askıya alma ve gözden geçirme gibi kötü davranışlar için öz sermaye azaltma cezaları uygulayan bir PoS algoritmasıdır. Meraklı okuyucular, FFG'nin "kuzeni" Casper CBC'nin, parçalama yol haritasının "Ethereum 3.0" bölümünde listelendiğini fark edecekler. (FFG ve CBC hakkında kapsamlı bir tartışma bu makalenin kapsamı dışındadır. Vitalik'in PoW ve FFG'yi karıştırmaya ilişkin notlarını ve azaltma koşullarını ve FFG kağıtlarını en aza indirme hakkındaki orta makalesini okumanızı öneririm.
Staker ne yapar?
Parçalanmanın amacı, herhangi bir düğümün ağın tam bir görüntüsüne sahip olmasını gerektirmeden durum bilgisini düğümler arasında bölmektir. Bu nedenle, hiçbir doğrulayıcı tüm parçaları doğrulamayacaktır. Bunun yerine işaret zinciri, diğer tüm parçaların doğrulanmasını koordine edecek ve tüm doğrulayıcılar bu işaret zincirini doğrulayacaktır. Her zaman periyodu (64 blok veya 6.4 dakika), işaret zinciri doğrulayıcıları karıştıracak ve onları bir parçaya atayacaktır. Bir parçaya atanan bir grup onaylayıcıya komite adı verilir. Komitenin 128 üyesi olacak. Aşama 0'da bu, işaretçi zincirinin her 6 dakikada bir mevcut doğrulayıcıları seçeceği ve sonraki 6 dakika içinde bir komite oluşturulacağı anlamına gelir. Aşama 1'de, işaret zinciri, 1024 parça için bir doğrulayıcılar komitesi atayacaktır. Kesin yöntem karmaşıktır. Komite seçim sürecini manipüle etme girişimlerini daha da engellemek için çok aşamalı bir rastgele sayı oluşturma süreci ve doğrulanabilir bir gecikme işlevi içerir.Ethereum 2.0 rastgele komiteleri seçer ve genellikle kilit görevler için komiteleri değiştirir. Her komite, parçalarının güvenliğini, canlılığını ve bütünlüğünü sağlamaktan ve işaret zinciri üzerindeki parçaların durumunu kanıtlamaktan sorumludur. İşaret zincirinin, kırıkların durumunu bilmesinin tek yolu bunlar ve bunun tersi de geçerlidir. Bunları tüm onaylayıcılardan oluşan bir havuzdan rastgele seçmek, tüm komitenin yalan söyleme veya aldatma olasılığını en aza indirebilir. Bunları dönüşümlü olarak kullanmak, genellikle kötü bir komitenin verebileceği zararı azaltmak içindir. Başka bir deyişle, kötü niyetli olan veya karlarını maksimize etmeye çalışan doğrulayıcıların komitenin üyesi olması ve ağa saldırılar başlatması zordur. Ayrıca, bir parça komitesini kontrol etme fırsatına sahip olsalar bile, bu kontrolün süresi 64 bloğu (6,4 dakika) geçmeyecektir.
Mühendisler için PoS Kanıtı
Ethereum 1.x'in çalışma kanıtı (PoW) ile Ethereum 2.0 hissesinin kanıtı arasındaki felsefi fark, sürekli bir süreç olsa da, POW / POS özelliklerindeki bazı farklılıkların gerçekten de doğrudan etkileyeceğini belirtmek gerekir. mühendis. Örneğin, PoW zinciri durumsuz SPV kanıtını ve NiPoPow tarafından özetlenen uzaktan durum izlemeyi desteklese de, PoS herhangi bir düşük durum iletişimi yasaklar. Öznellik, hafif durum sertifikasyonunu engeller. Başka bir deyişle, PoS uzak durum kanıtı, POW durumsuz SPV kanıtıyla kabaca aynı miktarda veri içerecektir, ancak tüm PoS geçmişinin önceden doğrulanması gerekir. Buna karşılık, vatansız SPV sertifikasyonu, doğrulamak için başka bilgiler gerektirmez. Bu, öznel bir PoS ortamında, çapraz parçalama veya çapraz zincir uygulamalarının işlevselliği azalttığı ve yönetim yükünü artırdığı anlamına gelir.Aşama 1 - Parçalama
Aşama 1'in amacı, parçalama zincirinin içeriği üzerinde bir fikir birliğine varmak, anlamı üzerinde bir fikir birliğine varmak değil. Başka bir deyişle, bu, genişletmek için parçalamayı kullanmaya çalışmaktan ziyade, parçalama yapısının bir deneme çalışmasıdır. İşaret zinciri, parça zincirini yapısı veya anlamı olmayan basit bir bit kümesi olarak ele alacaktır. Parça zincirinin henüz hesapları, varlıkları veya akıllı sözleşmeleri yok. Parça doğrulayıcıları, her periyotta her bir parça için işaret zinciri tarafından rastgele seçilir, sadece her bloğun içeriği üzerinde anlaşırlar. Tüm komiteler bir fikir birliğine ulaştığı ve parça üzerindeki işaret zincirini düzenli olarak güncellediği sürece, parça bloğunda görünen bilgi önemli değildir.
Parça doğrulama programı, çapraz bağlama adı verilen bir işlemle parçanın içeriğini ve durumunu doğrular. Basitçe ifade etmek gerekirse, komite işaret zincirindeki parça hakkında doğrulanabilir bilgileri (merkle kökü gibi) içermelidir. İkinci aşamada veya daha yüksek aşamada, çapraz bağlantı, parçalar arası iletişimi destekleyecektir. İşaret zinciri, birden fazla komiteden belirli bir çapraz bağlantının doğruluğunun kanıtını aldığında, işaret zinciri, tüm parçayı doğrulamadan çapraz bağın parçanın gerçek temsilcisi olduğuna güvenebilir. Komite, çapraz bağlantının etkinliği konusunda aynı fikirde değilse, komitenin yanlış olduğu ve cezalandırılması gerektiği açıktır. Bu, tüm parçaların güvenliğinin köküdür: Doğrulayıcının yanlış davranışı sonunda keşfedilecek ve işaret zinciri tarafından cezalandırılacaktır.
Aşama 1 ile ilgili özellikle ilginç hiçbir şey yok. Temel olarak konuşursak, çapraz bağlamanın kılavuz aşaması için kullanılır ve ayrıca parça referans işaret zinciri için simetrik bir mekanizmadır. Tasarımcılar bu mekanizmaların işe yarayacağına inanıyor gibi görünüyor. Başlıca açık konular, spesifikasyonlara ve uygulama stratejilerine odaklanır. Aşama 0'ın makul bir şartname düzeyine ulaşmasının yaklaşık bir yıl sürdüğünü düşünürsek, Aşama 1'in yaklaşık aynı zaman alacağını düşünüyorum. İlginç bir şekilde, Aşama 0'ın uygulanması şartname ile örtüşmektedir. Bugün bile, Ethereum 2.0 testnet'in yayınlanmasına 3 aydan az bir süre kala, faz 0 spesifikasyonu düzenli olarak değiştirilecek. Bu, Ethereum 2.0'ın geliştirme süresinin gelecekte çok farklı olacağı anlamına geliyor. İyimser bana bunun altı ay süreceğini söylese de, Aşama 0 teste girdikten sonra Aşama 1'in 12-18 aylık geliştirme süresi gerektireceğini kolayca tahmin edebiliriz.
2. Aşama-Akıllı Sözleşme
İkinci aşama sonunda bize aşina olduğumuz Ethereum sistemine benzer bir sistem getirecek. İkinci aşamanın yayınlanmasıyla birlikte, parça zinciri basit bir veri kabından yapılandırılmış bir zincir durumuna geçecektir. O zaman, BETH devredilebilir hale gelecek ve akıllı sözleşmeler yeniden sunulacak. Her parça, eWASM'ye dayalı bir sanal makineyi yönetecek (biz buna "EVM2" diyoruz) EVM2'nin Solidity'de aşina olduğumuz hesapları, sözleşmeleri, durumları ve diğer soyut içeriği destekleyebileceğini umuyoruz. Ancak, arka planda yapılan çok sayıda değişiklik, mevcut araçların çoğunu yok edebilir. Neyse ki, eWASM ekibi solc, trüf mantarı ve ganache için bazı temel çalışmalar yaptı. Aşama 2 test ağının başlatılması sırasında veya öncesinde EVM2'ye taşınan bazı tanıdık araçları görmeyi bekleyebiliriz.
Devlet kirasının, mevcut Solidity mühendisleri için bazı ilginç zorluklar ortaya çıkaran Aşama 2'de görünmesi muhtemeldir. Eyalet leasing, sözleşmeli geliştiricilerin ve kullanıcıların, kodu ve verileri süresiz olarak saklamak yerine, EVM2 depolama ücretlerini bir süre için desteklemesini gerektirecektir. Bu, kullanılmayan bilgilerin zaman içinde durumdan çıkmasını sağlayarak durum genişlemesini önler. Amaç, kullanıcıların (tüm düğümün değil) eyalet maliyetlerini ödemesine izin vermektir. Geliştiriciler birçok farklı model önerdiler, ancak net bir kazanan yok.
İlginç bir şekilde, bazı Ethereum yükseltme planlarının yayınlanması ve mükemmel Ethereum çekirdek geliştiricilerinin tavsiye etmesi ile birlikte, devlet kiralama, farklı yol haritalarının örtüşen tek kısmı olabilir. Bu nedenle, halihazırda konuşlandırılmış olan sözleşmeye devlet kiralaması için destek eklemeyi ve gelecekte kullanıcılara devlet kiralamasını geçirmek için bir model tasarlamayı şiddetle tavsiye ediyorum. Devlet kiralamasının kesin tasarımını bilmiyoruz, ancak maliyeti planlamalıyız.
Ayrıca 2. Aşamada ne olacağını bilmiyoruz. Hala araştırmanın ilk aşamasındadır ve çözülmemiş birkaç ana sorunu içerir. Gayri resmi şartname ve geliştirme sürecinin yanı sıra birinci aşamada ikinci aşamanın genişletilmesi göz önüne alındığında, ikinci aşamanın 2020'den önce inmesi olası görünmüyor. Diğer bir deyişle, Ethereum 2.0 bu yıl piyasaya sürülebilse de, en azından 2020'ye kadar Ethereum 2.0'ın varlık transferlerini veya akıllı sözleşmeleri desteklemesini beklememeliyiz.
Aşama 3-Zincir dışı durum depolaması
Akıllı sözleşmelerle ilgili konular hakkında daha fazla konuşmak için Faz 3'ün içeriğinden kısaca bahsedeceğiz. Aşama 3, zincire olabildiğince fazla durum aktararak zincir üzerindeki durumu en aza indirir. Tüm durumu zincirde depolamak yerine, bazı durum bilgilerini ve toplayıcıları depolar (toplayıcılar, uzun veri listelerini temsil eden kısa verilerdir; Merkle ağaçları bir tür toplayıcıdır). Tüm durumu zincir dışı depolamaktan kullanıcı sorumlu olacaktır. Kullanıcılar durumla etkileşim kurmak istediklerinde, işlemde mevcut durumun kanıtını içereceklerdir. Bu şekilde, bir doğrulama düğümünü çalıştırmak için kaynak gereksinimleri çok daha düşük olabilir. Farklı özelliklere ve performans özelliklerine sahip bazı toplayıcı tasarımları zaten mevcut, ancak henüz belirli bir seçim yapılmadı. Bu aşamada, kullanıcıları koordine etmek için zincir içi iletişimi kullanmayı bırakıyoruz, bu nedenle durumu diğer sistemler aracılığıyla senkronize etmeyi planlamalıyız. Zincir üzerindeki olaylar mühendisler için daha az faydalıdır çünkü zincir artık veri kullanılabilirliğini garanti edemez. 3. Aşamada, zincir dışı durumun sürdürülmesi ve elde edilmesi, dapp tasarımını sınırlayan önemli bir faktör olacaktır.
Aşama 4 - Akıllı Parçalama Sözleşmesi
Bununla birlikte, aşılamaz bir sorun hala var: ETH2.0 sözleşmeleri, Ethereum sözleşmeleri kadar güçlü olsalar da, kaçınılmaz olarak bir parçaya bağlanacaklar ve bir başkasıyla karşılaştırılamayacaklar. Sözleşme doğrudan etkileşim halindedir. Bu, parçalanmanın doğrudan bir sonucudur. Parçalamanın amacı, diğer parçaları doğrudan anlamadan eyaleti ayırmak ve farklı parçalara yerleştirmektir. Durumu bölerek ve doğrulayıcının iş yükünü en aza indirerek genişleme sağlar. Doğrudan etkileşim, doğrudan bilgi gerektirir. Ancak tasarıma göre, bir parça diğer parçalar hakkında doğrudan bilgiye sahip değildir. Yalnızca işaret zinciri ile zincirler arası iletişim yoluyla diğer parçaları öğrenir. Bu nedenle, parçalar arasında etkileşim kurmak istediğimizde, işaret zincirini beklememiz gerekir. Spesifik olarak, bu, SafeMath A parçasına dağıtılırsa, B parçasındaki kullanıcıların ona erişmek için biraz beklemesi veya B parçasına yeni bir SafeMath dağıtması gerektiği anlamına gelir.
SafeMath gibi basit yardımcı programlar, her bir parçaya (1024 parçaya ek olarak 1024 SafeMath) dağıtılacaktır. Peki ya Maker veya Compound gibi pazarlar? #DeFi birleştirilebilir finansmanın amacı, parçaların sınırlarını aştığında çok zordur. CDP aktivasyonu ve DAI toplama arasındaki uzun gecikme, kabul edilemez ekonomik kayıplara neden olabilir. Kullanıcılar DAI almadan önce piyasa değişirse ve CDP tasfiye edilirse ne olur? Pratikte bu, kullanıcıların akıllı sözleşmeler içeren her parça için bir hesaba sahip olmaları gerektiği anlamına gelebilir ve çapraz parçalı yapı tamamen işe yaramaz. Maker ve 0x, yalnızca her ikisi de aynı parçaya dağıtıldıklarında etkileşim kurabilir ve 0x kullanıcılarının da bu parça üzerinde varlıkları vardır.
Temel değiş tokuş: senkronizasyon veya genişleme
ETH2.0 tasarımcıları, çapraz parça iletişim sisteminin nihayetinde nasıl görüneceğini bilmiyorlar. Birçok öneriyi okuduktan sonra öyle görünüyor Anında geri bildirim ve öngörülebilirlik arasında temel bir denge vardır . Parçalamanın doğası değişmeyecek: kullanıcılar yine de parçalar arası iletişimi beklemelidir. Bununla birlikte, işlemin yerel ve uzaktan yürütme aşamalarını her bir parçaya sıkı veya gevşek bir şekilde bağlayabiliriz.Sıkı bağlantı önce beklemeyi sağlar. Parçalı iletişimden önce, işlem herhangi bir işlem yapmaz. Bunun aksine, parçayı şimdi ve daha sonra yürüterek işlemleri gevşek bir şekilde birleştirebiliriz. İşlem, yerel parça üzerinde yürütülür ve ardından parçalar arası iletişimden sonra uzaktaki parça üzerinde yürütülür. Gevşek bağlantı, kullanıcılara daha iyi bir deneyim sağlar. İşlemlerinin yerel olarak yürütüldüğünü anında görebilirler ve uzaktan yürütmenin gelecekte bir noktada gerçekleşeceğini bilirler. Ne yazık ki, gevşek bağlı bir işlemin uzak aşamasının sonucunu beklemeden bilemezler. Sıkı bir şekilde birleştirilen işlemler daha öngörülebilirdir. Uzak durum yerel ve uzaktan yürütme aşamaları arasında geçiş yapmadığından, kullanıcı sonuçları daha iyi anlar. Ancak sıkı bağlantı, kullanıcıların herhangi bir sonuç görmeden önce beklemesini gerektirir.
ETH2.0 iletişim modeli hakkında çok az bilgimiz var. Genişlemenin neredeyse tüm avantajlarından ödün vermeden çapraz paylaşımlı sözleşme çağrıları sağlayamayacağını biliyoruz. Burada okumayı bırakırsanız sizi suçlamayacağım çünkü 4. aşamada sadece bir zihin haritası ve bazı bulanık bağlantılar var. Bu durumun açık olmayan bir sonucu, ETH2.0'ın 4. Aşamadan önce karmaşık akıllı sözleşme sistemine bariz genişleme avantajları getirmeyeceğidir. Bundan önce, diğer sözleşmelerle etkileşime girmek isteyen akıllı sözleşmeler bir parça ile bir arada bulunmalıdır ve bu parçanın hızı ve genişleme etkisiyle sınırlıdır. ETH1.X ile karşılaştırıldığında, parçalama işleminin en fazla küçük bir sabit faktör ivmesi elde edebileceğini umuyoruz. Bu, Aşama 4 yayınlanmadan önce (2025 civarında), avantajlar küçük olduğu için akıllı sözleşme kodunu veya kullanıcıları taşımak için neredeyse hiçbir neden olmadığı anlamına gelir. Aynı zamanda, mühendisler ve dapp kullanıcıları arasındaki değiş tokuşları daha iyi anlamak için topluluk veya geliştiriciler tarafından önerilen bazı modelleri inceledim. Bunların benimseneceğini sanmıyorum, ancak buradaki değiş tokuşları anlamaya yardımcı olacaklarına inanıyorum. Tekrar söyle: Aşağıdaki tüm içerik spekülatiftir.
Temel model: makbuz (makbuz) ve kanıt (kanıt)
Tüm çapraz zincir iletişim biçimleri işaret zincirini kullanır. İşaret zinciri tüm parçaların durumunu alabildiğinden ve her parça işaret zincirinin durumunu etkilediğinden, onu parça zinciri ekosisteminin merkezi olarak kullanabiliriz. Bir zincirden diğerine mesajlar, bir anlamda işaret zinciri yoluyla iletilmelidir. Tam bir mesaj göndermek istemiyoruz çünkü bu, işaret zincirinin her bir işlemi kendi başına işlemesini gerektirir ve genişlemenin etkisini elde etmek tamamen imkansızdır.Aksine, Shard A'daki bir kullanıcı veya sözleşme Shard B ile etkileşime girmek istediğinde, Shard A'nın mesajla birlikte bir "alındı" oluşturmasına izin vereceğiz. Shard A, tüm fişlerini blok başlığında gönderir. İşaret zinciri, A'nın nihai onayını bekler ve ardından A'nın blok başlığına gönderir (makbuzların sunulması dahil). Shard B, işaretin son onayını beklemeli ve ardından onu işaret blok başlığına göndermelidir. Şu anda, makbuzlar ve sertifikalar dahil olmak üzere B'ye yeni bir işlem gönderebilirsiniz. Kanıt, makbuzun A, A'nın işarette ve işaretin B'de bulunduğunu göstermektedir. Bu şekilde, B üzerindeki sözleşme A'dan gönderilen mesaja güvenebilir. B'deki sözleşme bir yanıt göndermek isterse (dönüş değeri veya hata), biz de sırayla tüm süreci tekrar ederiz: Shard B bir alındı gönderir ve son olarak, makbuz Shard A'ya gider.
Bu sürecin neden çok zaman aldığını anlamak kolaydır. Dört iletişim adımının her birinin tamamlanması için birkaç dakika beklemesi gerekir! Ne yazık ki hiç beklemekten kaçınamayız. Uzak durumu belirlemek istiyorsak, her adımda nihai sonucu beklemeliyiz. Gidiş dönüş iletişimi için en iyi durum, dört son onay döngüsüdür. Başka bir deyişle, kullanıcı, üç döngüden sonra güven kazanabilir, çünkü kullanıcı, A parçasını görmeden önce B parçasının girişlerini görebilir. ETH2.0'ın 6,4 dakikalık epoch uzunluğunu kullanarak, kullanıcıların sonuçları görmek için 19 dakika beklemesi gerekir ve zincir üzerindeki sonuçları almak 26 dakika sürer.
Somut gelirler: parçalar arasında jeton geçişi
ERC20 tokenlerinin çok yönlülüğü, bugün Ethereum'da her yerde bulunmalarını sağlıyor. Bununla birlikte, ETH2.0, token'a bazı mantıksal sorunlar getiriyor. Akıllı sözleşme tüm belirteç bakiyelerini yönettiğinden ve akıllı sözleşme yalnızca tek bir parça üzerinde bulunduğundan, B parçasında A parçasından hiç simge yoktur. Bununla birlikte, bazı akıllı parçalar arası iletişimle, aynı jetonu birden fazla parçaya yerleştirebilir ve jeton sözleşmeleri arasında iki yönlü bir sabitleme oluşturarak jetonların parçalar arasında taşınmasına izin verebiliriz.Çözüm çok basit: tokenları dağıtırken (bunlara "cool cross-shard tokenlar" veya "CCT" diyelim), iki küçük ek fonksiyon eklemek için ERC20'yi kullanacağız: migrateSend ve migrateReceive fonksiyonları. Jetonları yok etmek ve makbuzlar oluşturmak için migrateSend kullanacağız. Makbuz, yok edilen jetonların sayısını ve alınan parçaların sayısını içerecektir. Makbuzu doğrulamak ve aynı miktarda CCT oluşturmak için migrateReceive kullanacağız. Daha sonra aynı token sözleşmesini her bir parçaya yerleştireceğiz. Artık migrateSend'i çağırarak bir parçadaki tokenları yok edebilir ve ardından etkili bir şekilde token oluşturmak için diğerinde migrateReceive çağrısı yapabiliriz. Token sözleşmemizi her parçaya yeniden yerleştirmemiz gerekiyor, ancak buna değer gibi görünüyor. Taşıma tek yönlüdür ve parçalar arası iletişim için en az iki nihai onay gerektirir. Bu nedenle, migrateSend'i çağırdıktan sonra, CCT'mizin alıcı parça üzerinde çalışabilmesi yaklaşık 10 dakika sürecektir.
Yank (çek)
Makbuzlar, bilgileri parçalara aktarmanın genel bir yoludur. Zincir üzerindeki herhangi bir bilgiyi makbuza koyabiliriz. Bu, tüm akıllı sözleşmeyi içerir. Yanking, sözleşmenin kodunu ve saklanan bilgileri makbuza ekleyerek sözleşmeleri parçalar arasında taşıma teklifidir. Sözleşme, A parçasından silinir (çekilir) ve makbuz geldikten sonra B parçasına yeniden dağıtılır. Kontrat Shard B üzerindeyken, Shard B'nin kontratıyla doğrudan iletişim kurabilir ve Shard B'nin durumu ile etkileşime girebilir. Hatta A dilimine geri çekilebilir.Bu, herhangi bir akıllı sözleşmenin başka herhangi bir akıllı sözleşmeyle iletişim kurmasına izin verecektir (parçalar arasında bekleme süresinden sonra). Ne yazık ki, makbuz sözleşmenin tamamını ve tüm depolamasını içerdiğinden, büyük bir sözleşmeyi veya çok sayıda kullanıcıyı taşımak çok maliyetli olacaktır. Makbuzun iletimi sırasında sözleşme hiçbir şekilde kullanılamaz. Parça A'dan çıkarıldı, ancak henüz Parça B'ye ulaşmadı. Bu, diğer tüm kullanıcıların sözleşmeyi B parçasına ulaşana kadar kullanamayacağı anlamına gelir. Dahası, yalnızca zaten Shard B'de bulunan kullanıcılar onunla etkileşim kurabilir. Bu nedenle, yanking, az kullanıcılı küçük sözleşmeler için en uygun olanıdır. Sıkıca bağlı yürütmeyi mümkün kılar, ancak evrensel bir çözüm olmaktan uzaktır.
Parça eşleştirme
Buradan biraz daha yaratıcı inşaat fikirlerine dönüyoruz. Makbuz, asenkron (gevşek bağlı) iletişimi mümkün kılmak için tasarlanmıştır. Bununla birlikte, eşzamanlı olarak da iletişim kurmak isteyebiliriz. Bunun için daha yaratıcı olmalıyız. Parça eşleştirme, sıkı bir şekilde bağlanmış yürütme sırasında bize olabildiğince az sorun çıkarmamıza izin veren basit bir tasarımdır.Parça eşleştirme basit bir çözümdür. Bu makalenin üçüncü paragrafında bahsettiğimiz gibi, parçaları her yükseklikte senkronize çiftler halinde sıralıyoruz. Bir parça başka bir parça ile her eşlendiğinde, herhangi bir parçanın kullanıcıları iki parça arasında sıkı bir şekilde bağlı durum güncellemeleri gerçekleştirebilir. Bu, eğer A ve B parçaları 7 yükseklikte eşleşirse, A ve B'nin tüm doğrulayıcılarının A ve B'nin tüm durumlarını bilmesi ve parçaların birlikte ilerlemesi veya hiç ilerlememesi gerektiği anlamına gelir. Bu modelde, A ve B arasında bir çapraz zincir işlemi gerçekleştirmeniz gerekiyorsa, A ve B'nin rastgele eşleşmesini beklemeniz gerekir. Ancak Vitalik, 100 parçalık bir durumu önerdi. 1.024 parça var ve 512 blok (yaklaşık bir saat) almasını bekliyoruz, ancak eşleştirme rastgele olduğu için daha uzun veya daha kısa sürebilir. Vitalik'in dediği gibi, birden fazla parçayla etkileşim kurmak istediğinizde, bu genişleme etkisi çok zayıftır.
Parçalanma alanı (bölge)
Bu, eşleştirmenin daha geniş bir versiyonudur. Her çağda, parçayı birden çok parçadan oluşan birkaç "bölgeye" böleriz. Bölgedeki fragmanların senkronize edilmesi gerekir, bu da bölgedeki tüm fragmanların yerel durumlarını birlikte güncellediği anlamına gelir. Senkronizasyon yoluyla bölge, parçalar arasında serbest geçişi ve bölgedeki herhangi bir sözleşmeyle doğrudan etkileşimi garanti eder, ancak bölge dışındaki herhangi bir parça ile iletişim kurmanın bir avantajı yoktur. Ek olarak, bölgeler, bölgedeki tüm kırıkların durumunu bilmek için doğrulayıcılara ihtiyaç duyduğundan, parçaların birçok genişletme avantajını ortadan kaldırırlar. Bir bölge 16 parçadan oluşuyorsa, toplam 15 / 1.024 (=% 1) ağın sıkı bir şekilde bağlanmış yürütmesini elde ederken, yaklaşık 15/16 (=% 94) genişleme avantajından ödün veriyoruz.Yükümlülükler
Parçalar arası (ve zincirler arası) iletişimin bariz olmayan bir özelliği, kullanıcıların mesaja ilgili zincirden daha hızlı güven kazanabilmesidir. Alice, Shard A'dan Shard B'ye 5 BETH gönderir, gönderdikten hemen sonra geleceğini bilerek. Bob, işlemin gönderildiğini görür ve onay için Shard A'ya gönderildikten sonra BETH'in Shard B'ye ulaşacağını bilir. Ancak, Shard B ve sözleşmesi, işaretçi zincirinin Shard A için nihai onay verebilmesi için birkaç dakika beklemelidir. Bu, paralar Shard A'ya harcandıktan sonra, bir cüzdanın bu fonları Shard B'de hızlı bir şekilde alıp harcayabileceği anlamına gelir. Başka bir deyişle, Bob Alice'in Shard B üzerindeki cüzdanından çalıştırılabilir bir IOU (IOU) alacak çünkü Bob, Alice'in yeterince ETH gönderdiğinden emin. Shard B'nin yeterli sayıda kullanıcısı Shard A'yı gözlemlemeye ve standart bir IOU kabul etmeye istekliyse, Shard A ETH gönderildikten hemen sonra Shard B'ye harcanabilir. Bununla birlikte, akıllı bir sözleşmeye uygulandığında, bu şema son derece karmaşık hale gelir, çünkü devletin yeri doldurulamaz, bu nedenle eyaletin IOU'sunun uygulanması imkansızdır, bu nedenle genel etkileşim için uygun değildir. Bu, sorumluluğu, gevşek bağlı bir kullanıcı deneyimi iyileştirmesi olarak ele almamız gerektiği anlamına gelir. Gevşek bağlamanın sıkı bağlamayı simüle etmesini ve belirli işlemleri hızlı bir şekilde gerçekleştirmesini sağlar.Konsensüs ve devlet ayrılığı
Daha karmaşık ve ilginç bir çözüm, fikir birliği sürecini durum güncelleme sürecinden ayırmaktır. Şu anda, Ethereum madencileri ve tam düğümler, blokları yalnızca blokta bulunan tüm durum güncellemelerini gerçekleştirdikten sonra kabul ediyor. Bu şekilde olmak zorunda değil. Bunun yerine, önce engellemeyi kabul edip durumu daha sonra güncelleyebilirler. Bu durumda, Ethereum'da olduğu gibi sistemin durumu konusunda fikir birliğine varamayacağız, ancak tüm parçalardaki tüm işlemlerin toplam geçmişi (veya "toplam sipariş") üzerinde fikir birliğine varacağız. Bunu yapmak, her bir parçanın diğer parçaların durumunu bilmeden hızla blok ekleyebileceği anlamına gelir. Bu, parçaların genişletmek için nasıl kullanılacağının ilkesidir. Ancak, işlemin parçaların durumu ve tüm ağ üzerindeki etkisi, tüm parçalar tamamlanana kadar bilinmeyecektir. Başka bir deyişle, durumun nihai onayı, segment içeriğinin nihai onayının gerisindedir.Kullanıcının bakış açısından: İşlemi hemen göndereceğiz ve bunların dahil edildiğini biliyoruz, ancak işlemin sonucunu belirlemek için biraz beklemeliyiz. Parçalar kesinleştikçe, kademeli olarak durum hakkında daha fazla bilgi alırız, ancak tüm parçalar nihai onaya ulaşana kadar tam olarak emin olamayız. Yükümlülüklere benzer şekilde, bazı durumlarda kullanıcılar işlemin sonucunu önceden belirleyebilir ve buna göre hareket edebilir.
Sonuç ve mühendislik yönü
ETH2.0, Ethereum'dan tamamen farklı bir sistem olacak. Uzun yıllar paralel olarak var olacaklar ve çok farklı özellik setlerine sahip olacaklar. Yakın gelecekte, ETH'den BETH'e tek yönlü bir peg bekliyoruz. Bir takas veya saklama hizmeti işletiyorsanız, BETH zincir üzerinde devredilebilir olmadan önce lütfen kullanıcılarınızı BETH saklama işlemlerinde ve stake etme (stake etme) konusunda nasıl destekleyeceğinizi düşünün. Uzun vadede, akıllı sözleşmelerin, iletişim kurup paylaşmadan paylaşmaya nasıl uyum sağlayabileceğini düşünmemiz gerekiyor. En önemlisi, geliştirme sürecine çok dikkat edin. ETH2.0 karmaşık ve sürekli gelişen bir sistemdir. Tüm dapp mühendislerinin ETH2.0 planını ve ilerlemesini açıkça anlamaları gerekir.
