Giriş: Toplama popüler hale geldiğinden beri, Sequencer'ın ademi merkeziyetçiliği her zaman Ethereum/Celestia topluluğunun odak noktası olmuştur ve aynı zamanda Layer2 araştırma ve geliştirmede aşılmaz bir dağdır. Bu bağlamda, farklı Toplama şemaları, bu konu için son derece geniş bir hayal gücü alanı sağlayarak, düğüm ademi merkeziyetçiliği hakkında fikirler önermiştir.
Bu makalenin yazarı, iyi bilinen ZKRollup projesi Aztec'i örnek alıyor ve Aztec Labs tarafından yakın zamanda önerilen B52 ve Fernet adlı iki teklifi, ZKR'nin okuyucular için sıralayıcı düğümlerinin dağıtılmasını nasıl gerçekleştirdiğini analiz etmek için başlangıç noktası olarak kullanıyor.
Teklif B52: İzinsiz sıralayıcı şeması
Teklif B52 aşağıdakileri gerçekleştirmeyi amaçlamaktadır (ideal olarak):
Merkezi olmayan sıralayıcı ağı, L2 düğümleri teklif verenlerin her turunu kendileri seçer
Merkezi olmayan kanıtlayıcı ağı, kanıtlayıcı düğümleri için düşük donanım gereksinimleri
Toplama, bir bütün olarak sansüre karşı iyi bir dirence sahiptir.
L2 tarafından üretilen MEV değeri, L2 düğümleri tarafından alınır.
L2 bloğu DA katmanına gönderildiğinde, daha etkili bir kesinlik elde edilebilir ve geri döndürülemez kesinlik, ValidityProof'un (geçerlilik kanıtı) sunulmasını beklemek zorundadır.
L2 Token iyi bir ekonomik modele sahip olabilir
Hem L2 blokları hem de işlem verileri L2 p2p ağında yayılır
L2, L1'in güvenliğini devralır
Bu şema, tüm L2 blok üretim sürecini üç zaman aşamasına ayırır:
Blok Teklif Penceresi(BPW)
BlokKabul Penceresi(BAW)
Devlet ilerlemeleri
Bunların arasında, BPW (blok önerisi) aşaması, birden çok sıralayıcı Seuqnecer'in farklı bloklar önerip rekabet ettiği ve Prover'ın oy vermek için bir aday blok seçtiği bir süreçtir.
BAW (Blok Kabulü), Prover'ın bir blok için bir Geçerlilik Kanıtı oluşturduğu ve bunu sunduğu süreçtir.
Blok Teklif Penceresi (blok teklif aşaması):
BPW üç aşamaya ayrılabilir: Blok Teklif, Blok Oylama, Toplama.
Blok Teklifi (BP) aşamasındaki herkes işlemleri toplayabilir ve kendi BP içeriğini yayınlayabilir. BP içeriği üç bölümden oluşacaktır: txs sipariş karması, kanıtlayıcı ödül yüzdesi, yakma belirteci miktarı
txs sipariş karması: Teklif sahibi, L2 işlem havuzundan (mempool) en değerli işlem grubunu seçip sıralar ve ardından bu işlem grubunun karma değerini oluşturduğu bloğa koyar.
kanıtlayıcı ödül yüzdesi: Sequencer tarafından Prover'a paylaşılan blok ödül yüzdesi
yanma belirteci miktarı: Teklif Sahibi tarafından imha edilmesi önerilen L2 Yerel Simgesinin sayısı ve ardından önerilen BP'yi L2 p2p ağına gönderir
Blok Oylama aşaması:
Prover, p2p ağındaki farklı Teklif Sahipleri tarafından önerilen BP'yi aldıktan sonra, kendisine en fazla ödülü kazandırabilecek BP'ye oy verecektir. Ancak, oyların bileşimi çok özeldir:
Oy={BlockHash, Kanıt Ağacı Dizini}
BlockHash, Prover'ın oy kullanacağı Teklifin hash'idir ve Kanıt Ağacı Dizini, Prover'ın oluşturmaya katılacağı Kanıt Ağacının yaprak indeks değeridir (daha sonra açıklanacaktır)
Toplama toplama: Teklif sahibi, L2 p2p ağında Provers'ın BP için oylarını toplar, toplar ve BP'ye koyar ve L1'e gönderir (her BP genellikle yalnızca kendisiyle ilgili oylama kayıtlarını içerir).
Burada BP'nin seçilip Rollp defterine dahil edilebilmesi için ön koşulların vurgulanması gerekmektedir:
En yüksek puana sahip olun:
SCORE(y) = SAYI_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x), BP tarafından elde edilen Prover oylarının sayısıdır ve BURN_BID, BP tarafından imha edilmesi önerilen L2 Jetonlarının sayısıdır. BURN_BID ne kadar yüksek olursa, sonunda BP öneren kişi o kadar az ödül alacaktır, dolayısıyla bu değer doğru şekilde ayarlanmalıdır.
Aynı zamanda, muhatabın Blok Teklif Penceresi sona ermeden L1'e sunulması ve ilgili geçerlilik kanıtının Blok Kabul Penceresi sona ermeden önce L1'e yüklenmesi gerekir.
Not: BP puanlarının hesaplanmasında, oy sayısı en büyük orana sahiptir ve bunu yakma jetonlarının sayısı takip eder. Aynı zamanda, B52 şeması, birden çok teklif sahibinin (aslında sıralayıcıların) etkili bir BP kotası için rekabet etmesine izin verir.
B52 şeması, Teklif Sahibinin (sıralayıcı) kendi BP'sinde (EIP1559 yöntemine benzer şekilde) yazma belirteçlerinin sayısını önceden hisse belirteçleri olmadan belirtmesini gerektirir, bu da ağı daha izinsiz hale getirebilir (erişim izni yok) ve L2 Native Token için de faydalıdır, deflasyon üretir.
Ek olarak, BP tam işlem verilerini içermez, yalnızca işlem dizisinin karmasını içerir.Bunun nedeni, MEV'nin diğer Teklif Sahipleri tarafından gözetlenmesini önlemeyi amaçlayan Ethereum PBS şemasına benzer.
Blok Kabul Penceresi (blok kabul aşaması) detaylı açıklama:
Blok Teklif Penceresi sona erdikten sonra, Prover'ın muhataplarına karşılık gelen eksiksiz işlem verilerini göstermesi gerekir. Prover tarafından oylanan BP seçilirse (en yüksek puan L1 sözleşmesi aracılığıyla sorgulanabilir), oylama sırasında verilen Kanıt Ağacı Dizinine karşılık gelen Alt Kanıt Ağacını oluşturmaları gerekir.
Aztek bloğunun 2^13=16384 işlem içerdiğini ve 2048 kanıtlayıcı olduğunu varsayarsak, her kanıtlayıcı 2^3=8 işlemden oluşan bir alt kanıt ağacı oluşturur ve ardından kanıtlayıcı kendi oluşturduğu alt kanıt ağacını L2 p2p'de yayınlar. ağ. Teklif sahibi bunu aldıktan sonra, tüm alt kanıt ağaçlarını bir blok kanıtta toplayacaktır.
Daha sonra Propsoer, toplu kanıtı L1 Toplama sözleşmesine gönderir ve sözleşme, kanıtın ve ilgili durum geçiş sonuçlarının doğruluğunu doğrular. Burada, Kanıtlayıcı kasıtlı olarak ispatı sunmazsa, sadece Teklif Sahibi tarafından vaat edilen blok ödül temettüsünü alamayacak, aynı zamanda kesilecektir, çünkü bir Kanıtlayıcı olmak için ihtiyacı vardır. Jetonu önceden taahhüt edin. Bu nedenle, Öneren'den (Sequencer) farklı olarak, Kanıtlayan İzinsiz değildir.
State Advances (durum ilerleme aşaması) ayrıntılı açıklama:
Blok Kabul Penceresi sona erdikten sonra Toplama sözleşmesi, Toplama defterine dahil edilmek üzere en yüksek puana sahip bir blok seçecek ve blok ödül Ödülünü Teklif Sahibi (Sıralayıcı) tarafından beyan edilen orana göre sırasıyla Teklif Sahibine ve Kanıtlayıcıya gönderecektir. ilerlemek.
Yukarıdaki Aztec'in B52 çözümüdür. Ancak bu makalenin yazarı, B52 önerisiyle ilgili bazı potansiyel sorunlar olduğuna inanıyor:
Soru 1: En yüksek puana sahip bloğun geçerlilik kanıtı eksikse. Teklifte verilen çözüm şudur: Teklif Veren ispatın yalnızca %50'sini sağlarsa blok ödüllerinin yalnızca %50'sini alabilir, böylece Teklif Veren kasıtlı olarak tam bir ispat sunmamak için hiçbir motivasyona sahip olmaz. Prover aynı zamanda doğrudan sözleşmeye kanıt sunabilir.
Teklifin açıklamasına göre, tamamlanmış işlemlerin geçerlilik kanıtı olmadan bir bloğun kabul edilmesi kabul edilebilir. Bu aslında mantıksızdır: çünkü: zkrollup, yalnızca geçerlilik kanıtı verildiğinde bu bloğa karşılık gelen yeni durumun geçerli olduğunu beyan eder.
Teklif sahibi tarafından L1'e sunulan toplam kanıtta belirli bir işlemin kanıtı eksikse, bu işlemden sonra gerçekleşen tüm işlemlerin durum geçiş kanıtlarının geçersiz olduğu açıktır (çünkü işlemler sıralı olarak yürütülür ve durum bağımlılıkları vardır), biz Bu bloğa karşılık gelen yeni durumun geçerli olduğunu doğrulamak da imkansızdır.
Bu nedenle, şu anda makul yol, tüm işlem kanıtları sunulana kadar sonsuza kadar bekleyen Blok Kabul Penceresine girmek olmalıdır.
Soru 2: **En yüksek skora sahip blok geçersiz blok ise (B52 şemasında bu açıklanmamıştır). **BP yalnızca işlem dizisinin karmasını içerir, bu nedenle kötü niyetli bir teklif sahibi, çifte harcama işlemleri gibi kasıtlı olarak sorunlu işlemler oluşturabilir. Yani şu anda, L1 sözleşmesine herkesin yasadışı bir kanıt sunabileceği bir işlev eklemek gerçekten gerekli.Bu yasadışı kanıt, en yüksek puana sahip BP'nin geçersiz bir blok olduğunu kanıtlamak için kullanılır.
Ve bu tür bir rapor ödüllendirilmeli, teklif sahibi tarafından sözleşmeye gönderilen yazma jetonunu yasadışı kanıtı sunan raportör düğüme ödüllendirebiliriz.
**İlginç düşünce:**Amca blokları ve gereksiz Kanıtlama Çalışması hakkında: B52 şeması, aslında her turda en yüksek puana sahip BP göründükten sonra bu turda amca olarak görünen diğer BP'leri (tam kanıtları sunmuş olan) kullanacaktır. belirli bir amca blok ödülü atayın.
Bu aslında ETH POW konsensüs mekanizmasının yaklaşımını izler.Aşırı bilgi işlem gücü yoğunlaşmasını önlemek için, küçük madencilik havuzlarının/bireysel madencilerin çıkarlarını korumak için blok ödüllerinin bir kısmını kabul edilmeyen blok önerenlere (madenciler) tahsis etmek gerekir. Bilgi işlem gücü büyük madencilik havuzlarının tekelindedir. Bu nedenle, Ethereum'un iyi performans gösterdiği amca blok mekanizmasını benimsemek de çok akıllıca bir seçimdir.
Toplama ademi merkeziyetçiliği açısından B52 teklifinin önemi: Teklif veren merkezsizdir ve taahhüt gerektirmez ve giriş eşiği düşüktür; ancak en değerli blokları kendiniz inşa etmeniz ve oy toplamanız gerektiğinden ve tüm Kanıtları toplayın.Aslında, Teklif Sahibinin donanım eşiği teklifte belirtildiği kadar düşük değildir (örneğin, bant genişliği çok düşük olmayabilir).
Bu nedenle, sonunda Mev-Boost Builder'a benzer şekilde nispeten merkezi bir ağ haline gelecektir, çünkü sonunda blok oluşturabilen teklif sahibi genellikle MEV'yi yakalamada en iyi olan Block Builder'dır.
Aynı zamanda, B52 planındaki Prover'ın varlıkları taahhüt etmesi gerekir, ancak tüm blok kanıtını tamamen oluşturması gereken planlarla karşılaştırıldığında yalnızca alt ağaç kanıtın oluşturulması gerektiğinden, **Prover'ın ademi merkeziyet derecesi daha iyi (donanım gereksinimleri azaltılabilir). **
Aktif Canlılık: Genel ağ Canlılığı iyidir, çünkü L2'nin işlemleri ve oyları/BP'yi yayınlamak için kendi p2p ağı vardır ve Sequencer ve Prover görece dağıtıktır. Ancak yukarıda bahsettiğimiz iki sorunu çözmemiz gerekiyor, birincisi en yüksek puana sahip bloğun legal bir blok olması, ikincisi ise yeni bir bloka girmeden önce tam blok ispatının L1'e sunulmasını beklemesi gerekiyor. durum. Bu nedenle, tx kanıtının belirli bir bölümünün olmaması nedeniyle tüm Rollup ağının arızalanmasını (kesinti) önlemek için daha etkili bir teşvik mekanizmasına ihtiyaç vardır.
**Sansür Direnci: **Herkesin blok önerisi BP'yi yayınlayabileceğini garanti edebilirsek ve yalnızca Teklif Sahibinin blok kanıtı sunamayacağından emin olabilirsek, ağ sansüre karşı iyi bir dirence sahip olacaktır.
**Kesinlik: **L2'nin kesinliği, ağın canlılığıyla yakından ilgilidir, çünkü doğrulanmış nihai kesinliğin yine de Blok Kanıtının sunulmasını beklemesi gerekir, ancak aslında bir BP'ye karşılık gelen blok içeriğine de güvenebilirsiniz. en yüksek puana sahip (kötü niyetli işlemler içermediği sürece).
Bu blok, Blok Kabul Penceresinin başında gösterilecektir, bu da bir kullanıcı olarak sadece bir Blok Teklif Penceresi ve gönderdiğiniz işlemin kabul edilebileceği bloğu beklemeniz gerektiği anlamına gelir.
L1 güvenliğini devral: Geçerlilik kanıtı göndererek durumunu güncelleyen bir L2 olarak, L1'in güvenliğini devralabilir.
Teklif Fernet'i: Yasal Teklif Sahibini seçmek için VDF'yi tanıtın
Fernet düzeni tanıtımı: VDF aracılığıyla, blok oluşturma döngüsünün her turunda, Komitedeki farklı düğümler (yani Sıralayıcı düğümleri kümesi) ve Sıralayıcı tarafından önerilen blok için tahmini bir puan belirlenir. en yüksek final puanı geçerli taş olacaktır.
**Öncelikle Komiteye nasıl katılınır? Aslında L1'de 16 ETH taahhüt etmeniz, **ve rehin işlemi tamamlandıktan sonra 4 L1 bloğu beklemeniz ve ardından Sequencer Committee'ye katılmanız gerekiyor. Sequencer Committee'den çıkmak için L1 kontratındaki Stake fonksiyonunu çağırmanız gerekiyor ve 3 gün sonra katkınızın kalan kısmını geri alabilirsiniz.
O halde, VDF nedir? Doğrulanabilir Gecikme İşlevi, doğrulanabilir bir gecikme işlevidir. Bu matematiksel işlev, katı seri yürütme özelliklerini karşılar. Bazı hesaplama adımlarını gerçekleştirecek ve en azından tahmin edilebilir bir süre tüketecektir. VDF tarafından hesaplanan değeri, tekdüze bir normal dağılımı sağlayan Puan olarak kaydediyoruz.Bu nedenle, Sequencer, VDF Puanını hesapladıktan sonra, yasal teklif sahibi olarak seçilme olasılığını değerlendirebilir. **
Sıralayıcının VDF'si şu şekilde hesaplanır:
Skor = VDF(özel anahtar, genel girişler)
genel girişler = {geçerli blok numarası, randao}
randao, Sıralayıcının gelecekteki tüm blok yüksekliklerinde kendi VDF Puanını önceden hesaplamasını önlemek için kullanılan rastgele bir sayıdır.
Fernet'in tüm süreci temel olarak 3 aşamaya ayrılmıştır:
Teklif Aşaması 2. Kanıtlama Aşaması 3. Kesinleştirme
Bu aşamanın başlangıcında, her Sıralayıcı mevcut blok yüksekliğinde karşılık gelen VDF Puanını hesaplamak için VDF'yi kullanacaktır. Sequencer, VDF Puanının bu kez bir blok oluşturma hakkını kazanacağını düşünürse (Puanın normal bir dağılımı karşıladığını varsayarsak), Tekliften L1'e bir Toplama sözleşmesi sunacaktır. Teklif şunları içerir: önceki L2 bloğuna işaret eden işlem dizisinin karması.
kanıtlanmamış blok: Yalnızca Toplama sözleşmesi Teklifinin blok içerikleri sunulur. Ardından, **Sequencer'ın kanıtlanmamış bloğa karşılık gelen blok içeriklerini ve VDF'nin kanıtını L2 p2p ağına göndermesi gerekir. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 L1 blok (bu faz 50 L1 blok, yaklaşık 10 dakika sürecektir)
Prover, Blok İçeriklerindeki ilgili tüm işlemleri L2 p2p ağından alır ve daha yüksek VDF Puanına sahip bloklar için Kanıt oluşturur. Proof'un inşası aynı zamanda paralel olarak işbirliği yapan birden fazla Provers yöntemini benimser (B52 şemasına benzer).
Bu nedenle, Sequencer'ın birden çok farklı işleme karşılık gelen Kanıtları sonunda bir Blok Kanıtında (VDF Kanıtı dahil) toplaması ve bunu L1'in Toplama sözleşmesine sunması gerekir. Toplama sözleşmesine Blok Kanıtı göndermiş olan herkes Blok İçerikleri gönderebilir.
Sonlandırma: Bloğu Sonlandırmak için bir L1 işlemi göndermek gerekir.Sonlandırılabilecek bir bloğun karşılanması gerekir: Blok İçerikleri ve Blok Kanıtı gönderilir ve işaret edilen önceki blok Sonlandırılmalıdır. Yukarıdaki koşulları karşılama temelinde, en yüksek Puana da sahip olmalısınız.
Ardışık blok üretim mekanizması: Fernet'in bir boru hattı blok üretim mekanizmasını benimsediği belirtilmelidir.Nth bloğunun Proposal aşaması bittiğinde, N+1th bloğunun Proposal aşaması başlar (Aptos ve diğer genel zincirlerin de benzer uygulamaları vardır). Ancak N+1. blok için, L1 Final Block işlemini gönderip Final Block olmak için doğrulamayı geçebilmesi için N. bloğun Finalize edilmesini beklemesi gerekir.
Potansiyel saldırı boyutları: En yüksek VDF Puanına sahip Sıralayıcı, Blok İçeriklerini kasıtlı olarak L2 p2p'de yayınlamazsa, bloğun yeniden düzenlenmesine yol açabilir.
Yeniden düzenlemedeki L2 blok sayısının hesaplanması: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blok
Çözüm: Her L2 yuvası (blok oluşturma zaman dilimi) için yalnızca bir tam aday bloğa sahip olmaktan kaçınmak için amca blok mekanizmasını artırın.
Ademi merkeziyet açısından Fernet'in önemi: Sıralayıcı, Sıralayıcı Komitesine 16 ETH sözü vererek katılır ve giriş eşiği yüksek değildir (ancak düşük değildir). Kanıtlayan herhangi bir rehin gerektirmez, ancak Kanıtlayan Kanıt üretmezse ceza yoktur. Bu temelde B52 şemasının tersidir.
**Aktif Canlılık: **VDF+uncle blok mekanizması her turda birden fazla blok üreticisi olmasını sağlayabildiğinden, genel ağın Canlılığı garanti edilebilir.
**MEV: **MEV hususları en özel olanıdır. Plan, PBS'yi tanıtmayı planlıyor, böylece bir Sıralayıcı olarak yüksek bir VDF Puanı hesapladıktan sonra, daha değerli bir blok inşa etmek için doğrudan bir Blok Oluşturucu bulabilirsiniz.
**Sansür Direnci: **Fernet ayrıca Ethereum ile aynı PBS mekanizmasını benimseyecektir, bu nedenle özünde Fernet'in anti-sansür sorunu Ethereum'un PBS'sininkine eşdeğerdir.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Aztec Labs'ın B52 teklifini ayrıştırma: ZK-Rollup, sıralayıcı düğümlerin dağıtılmasını nasıl gerçekleştiriyor?
Yazar: 0xhhh, EthStorage
Editör: Faust, Geek web3
Giriş: Toplama popüler hale geldiğinden beri, Sequencer'ın ademi merkeziyetçiliği her zaman Ethereum/Celestia topluluğunun odak noktası olmuştur ve aynı zamanda Layer2 araştırma ve geliştirmede aşılmaz bir dağdır. Bu bağlamda, farklı Toplama şemaları, bu konu için son derece geniş bir hayal gücü alanı sağlayarak, düğüm ademi merkeziyetçiliği hakkında fikirler önermiştir.
Bu makalenin yazarı, iyi bilinen ZKRollup projesi Aztec'i örnek alıyor ve Aztec Labs tarafından yakın zamanda önerilen B52 ve Fernet adlı iki teklifi, ZKR'nin okuyucular için sıralayıcı düğümlerinin dağıtılmasını nasıl gerçekleştirdiğini analiz etmek için başlangıç noktası olarak kullanıyor.
Teklif B52: İzinsiz sıralayıcı şeması
Teklif B52 aşağıdakileri gerçekleştirmeyi amaçlamaktadır (ideal olarak):
Merkezi olmayan sıralayıcı ağı, L2 düğümleri teklif verenlerin her turunu kendileri seçer
Merkezi olmayan kanıtlayıcı ağı, kanıtlayıcı düğümleri için düşük donanım gereksinimleri
Toplama, bir bütün olarak sansüre karşı iyi bir dirence sahiptir.
L2 tarafından üretilen MEV değeri, L2 düğümleri tarafından alınır.
L2 bloğu DA katmanına gönderildiğinde, daha etkili bir kesinlik elde edilebilir ve geri döndürülemez kesinlik, ValidityProof'un (geçerlilik kanıtı) sunulmasını beklemek zorundadır.
L2 Token iyi bir ekonomik modele sahip olabilir
Hem L2 blokları hem de işlem verileri L2 p2p ağında yayılır
L2, L1'in güvenliğini devralır
Bu şema, tüm L2 blok üretim sürecini üç zaman aşamasına ayırır:
Bunların arasında, BPW (blok önerisi) aşaması, birden çok sıralayıcı Seuqnecer'in farklı bloklar önerip rekabet ettiği ve Prover'ın oy vermek için bir aday blok seçtiği bir süreçtir.
BAW (Blok Kabulü), Prover'ın bir blok için bir Geçerlilik Kanıtı oluşturduğu ve bunu sunduğu süreçtir.
Blok Teklif Penceresi (blok teklif aşaması):
BPW üç aşamaya ayrılabilir: Blok Teklif, Blok Oylama, Toplama.
Blok Teklifi (BP) aşamasındaki herkes işlemleri toplayabilir ve kendi BP içeriğini yayınlayabilir. BP içeriği üç bölümden oluşacaktır: txs sipariş karması, kanıtlayıcı ödül yüzdesi, yakma belirteci miktarı
txs sipariş karması: Teklif sahibi, L2 işlem havuzundan (mempool) en değerli işlem grubunu seçip sıralar ve ardından bu işlem grubunun karma değerini oluşturduğu bloğa koyar.
kanıtlayıcı ödül yüzdesi: Sequencer tarafından Prover'a paylaşılan blok ödül yüzdesi
yanma belirteci miktarı: Teklif Sahibi tarafından imha edilmesi önerilen L2 Yerel Simgesinin sayısı ve ardından önerilen BP'yi L2 p2p ağına gönderir
Blok Oylama aşaması:
Prover, p2p ağındaki farklı Teklif Sahipleri tarafından önerilen BP'yi aldıktan sonra, kendisine en fazla ödülü kazandırabilecek BP'ye oy verecektir. Ancak, oyların bileşimi çok özeldir:
Oy={BlockHash, Kanıt Ağacı Dizini}
BlockHash, Prover'ın oy kullanacağı Teklifin hash'idir ve Kanıt Ağacı Dizini, Prover'ın oluşturmaya katılacağı Kanıt Ağacının yaprak indeks değeridir (daha sonra açıklanacaktır)
Toplama toplama: Teklif sahibi, L2 p2p ağında Provers'ın BP için oylarını toplar, toplar ve BP'ye koyar ve L1'e gönderir (her BP genellikle yalnızca kendisiyle ilgili oylama kayıtlarını içerir).
Burada BP'nin seçilip Rollp defterine dahil edilebilmesi için ön koşulların vurgulanması gerekmektedir:
En yüksek puana sahip olun:
SCORE(y) = SAYI_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x), BP tarafından elde edilen Prover oylarının sayısıdır ve BURN_BID, BP tarafından imha edilmesi önerilen L2 Jetonlarının sayısıdır. BURN_BID ne kadar yüksek olursa, sonunda BP öneren kişi o kadar az ödül alacaktır, dolayısıyla bu değer doğru şekilde ayarlanmalıdır.
Aynı zamanda, muhatabın Blok Teklif Penceresi sona ermeden L1'e sunulması ve ilgili geçerlilik kanıtının Blok Kabul Penceresi sona ermeden önce L1'e yüklenmesi gerekir.
Not: BP puanlarının hesaplanmasında, oy sayısı en büyük orana sahiptir ve bunu yakma jetonlarının sayısı takip eder. Aynı zamanda, B52 şeması, birden çok teklif sahibinin (aslında sıralayıcıların) etkili bir BP kotası için rekabet etmesine izin verir.
B52 şeması, Teklif Sahibinin (sıralayıcı) kendi BP'sinde (EIP1559 yöntemine benzer şekilde) yazma belirteçlerinin sayısını önceden hisse belirteçleri olmadan belirtmesini gerektirir, bu da ağı daha izinsiz hale getirebilir (erişim izni yok) ve L2 Native Token için de faydalıdır, deflasyon üretir.
Ek olarak, BP tam işlem verilerini içermez, yalnızca işlem dizisinin karmasını içerir.Bunun nedeni, MEV'nin diğer Teklif Sahipleri tarafından gözetlenmesini önlemeyi amaçlayan Ethereum PBS şemasına benzer.
Blok Kabul Penceresi (blok kabul aşaması) detaylı açıklama:
Blok Teklif Penceresi sona erdikten sonra, Prover'ın muhataplarına karşılık gelen eksiksiz işlem verilerini göstermesi gerekir. Prover tarafından oylanan BP seçilirse (en yüksek puan L1 sözleşmesi aracılığıyla sorgulanabilir), oylama sırasında verilen Kanıt Ağacı Dizinine karşılık gelen Alt Kanıt Ağacını oluşturmaları gerekir.
Aztek bloğunun 2^13=16384 işlem içerdiğini ve 2048 kanıtlayıcı olduğunu varsayarsak, her kanıtlayıcı 2^3=8 işlemden oluşan bir alt kanıt ağacı oluşturur ve ardından kanıtlayıcı kendi oluşturduğu alt kanıt ağacını L2 p2p'de yayınlar. ağ. Teklif sahibi bunu aldıktan sonra, tüm alt kanıt ağaçlarını bir blok kanıtta toplayacaktır.
Daha sonra Propsoer, toplu kanıtı L1 Toplama sözleşmesine gönderir ve sözleşme, kanıtın ve ilgili durum geçiş sonuçlarının doğruluğunu doğrular. Burada, Kanıtlayıcı kasıtlı olarak ispatı sunmazsa, sadece Teklif Sahibi tarafından vaat edilen blok ödül temettüsünü alamayacak, aynı zamanda kesilecektir, çünkü bir Kanıtlayıcı olmak için ihtiyacı vardır. Jetonu önceden taahhüt edin. Bu nedenle, Öneren'den (Sequencer) farklı olarak, Kanıtlayan İzinsiz değildir.
State Advances (durum ilerleme aşaması) ayrıntılı açıklama:
Blok Kabul Penceresi sona erdikten sonra Toplama sözleşmesi, Toplama defterine dahil edilmek üzere en yüksek puana sahip bir blok seçecek ve blok ödül Ödülünü Teklif Sahibi (Sıralayıcı) tarafından beyan edilen orana göre sırasıyla Teklif Sahibine ve Kanıtlayıcıya gönderecektir. ilerlemek.
Yukarıdaki Aztec'in B52 çözümüdür. Ancak bu makalenin yazarı, B52 önerisiyle ilgili bazı potansiyel sorunlar olduğuna inanıyor:
Soru 1: En yüksek puana sahip bloğun geçerlilik kanıtı eksikse. Teklifte verilen çözüm şudur: Teklif Veren ispatın yalnızca %50'sini sağlarsa blok ödüllerinin yalnızca %50'sini alabilir, böylece Teklif Veren kasıtlı olarak tam bir ispat sunmamak için hiçbir motivasyona sahip olmaz. Prover aynı zamanda doğrudan sözleşmeye kanıt sunabilir.
Teklifin açıklamasına göre, tamamlanmış işlemlerin geçerlilik kanıtı olmadan bir bloğun kabul edilmesi kabul edilebilir. Bu aslında mantıksızdır: çünkü: zkrollup, yalnızca geçerlilik kanıtı verildiğinde bu bloğa karşılık gelen yeni durumun geçerli olduğunu beyan eder.
Teklif sahibi tarafından L1'e sunulan toplam kanıtta belirli bir işlemin kanıtı eksikse, bu işlemden sonra gerçekleşen tüm işlemlerin durum geçiş kanıtlarının geçersiz olduğu açıktır (çünkü işlemler sıralı olarak yürütülür ve durum bağımlılıkları vardır), biz Bu bloğa karşılık gelen yeni durumun geçerli olduğunu doğrulamak da imkansızdır.
Bu nedenle, şu anda makul yol, tüm işlem kanıtları sunulana kadar sonsuza kadar bekleyen Blok Kabul Penceresine girmek olmalıdır.
Soru 2: **En yüksek skora sahip blok geçersiz blok ise (B52 şemasında bu açıklanmamıştır). **BP yalnızca işlem dizisinin karmasını içerir, bu nedenle kötü niyetli bir teklif sahibi, çifte harcama işlemleri gibi kasıtlı olarak sorunlu işlemler oluşturabilir. Yani şu anda, L1 sözleşmesine herkesin yasadışı bir kanıt sunabileceği bir işlev eklemek gerçekten gerekli.Bu yasadışı kanıt, en yüksek puana sahip BP'nin geçersiz bir blok olduğunu kanıtlamak için kullanılır.
Ve bu tür bir rapor ödüllendirilmeli, teklif sahibi tarafından sözleşmeye gönderilen yazma jetonunu yasadışı kanıtı sunan raportör düğüme ödüllendirebiliriz.
**İlginç düşünce:**Amca blokları ve gereksiz Kanıtlama Çalışması hakkında: B52 şeması, aslında her turda en yüksek puana sahip BP göründükten sonra bu turda amca olarak görünen diğer BP'leri (tam kanıtları sunmuş olan) kullanacaktır. belirli bir amca blok ödülü atayın.
Bu aslında ETH POW konsensüs mekanizmasının yaklaşımını izler.Aşırı bilgi işlem gücü yoğunlaşmasını önlemek için, küçük madencilik havuzlarının/bireysel madencilerin çıkarlarını korumak için blok ödüllerinin bir kısmını kabul edilmeyen blok önerenlere (madenciler) tahsis etmek gerekir. Bilgi işlem gücü büyük madencilik havuzlarının tekelindedir. Bu nedenle, Ethereum'un iyi performans gösterdiği amca blok mekanizmasını benimsemek de çok akıllıca bir seçimdir.
Toplama ademi merkeziyetçiliği açısından B52 teklifinin önemi: Teklif veren merkezsizdir ve taahhüt gerektirmez ve giriş eşiği düşüktür; ancak en değerli blokları kendiniz inşa etmeniz ve oy toplamanız gerektiğinden ve tüm Kanıtları toplayın.Aslında, Teklif Sahibinin donanım eşiği teklifte belirtildiği kadar düşük değildir (örneğin, bant genişliği çok düşük olmayabilir).
Bu nedenle, sonunda Mev-Boost Builder'a benzer şekilde nispeten merkezi bir ağ haline gelecektir, çünkü sonunda blok oluşturabilen teklif sahibi genellikle MEV'yi yakalamada en iyi olan Block Builder'dır.
Aynı zamanda, B52 planındaki Prover'ın varlıkları taahhüt etmesi gerekir, ancak tüm blok kanıtını tamamen oluşturması gereken planlarla karşılaştırıldığında yalnızca alt ağaç kanıtın oluşturulması gerektiğinden, **Prover'ın ademi merkeziyet derecesi daha iyi (donanım gereksinimleri azaltılabilir). **
Aktif Canlılık: Genel ağ Canlılığı iyidir, çünkü L2'nin işlemleri ve oyları/BP'yi yayınlamak için kendi p2p ağı vardır ve Sequencer ve Prover görece dağıtıktır. Ancak yukarıda bahsettiğimiz iki sorunu çözmemiz gerekiyor, birincisi en yüksek puana sahip bloğun legal bir blok olması, ikincisi ise yeni bir bloka girmeden önce tam blok ispatının L1'e sunulmasını beklemesi gerekiyor. durum. Bu nedenle, tx kanıtının belirli bir bölümünün olmaması nedeniyle tüm Rollup ağının arızalanmasını (kesinti) önlemek için daha etkili bir teşvik mekanizmasına ihtiyaç vardır.
**Sansür Direnci: **Herkesin blok önerisi BP'yi yayınlayabileceğini garanti edebilirsek ve yalnızca Teklif Sahibinin blok kanıtı sunamayacağından emin olabilirsek, ağ sansüre karşı iyi bir dirence sahip olacaktır.
**Kesinlik: **L2'nin kesinliği, ağın canlılığıyla yakından ilgilidir, çünkü doğrulanmış nihai kesinliğin yine de Blok Kanıtının sunulmasını beklemesi gerekir, ancak aslında bir BP'ye karşılık gelen blok içeriğine de güvenebilirsiniz. en yüksek puana sahip (kötü niyetli işlemler içermediği sürece).
Bu blok, Blok Kabul Penceresinin başında gösterilecektir, bu da bir kullanıcı olarak sadece bir Blok Teklif Penceresi ve gönderdiğiniz işlemin kabul edilebileceği bloğu beklemeniz gerektiği anlamına gelir.
L1 güvenliğini devral: Geçerlilik kanıtı göndererek durumunu güncelleyen bir L2 olarak, L1'in güvenliğini devralabilir.
Teklif Fernet'i: Yasal Teklif Sahibini seçmek için VDF'yi tanıtın
Fernet düzeni tanıtımı: VDF aracılığıyla, blok oluşturma döngüsünün her turunda, Komitedeki farklı düğümler (yani Sıralayıcı düğümleri kümesi) ve Sıralayıcı tarafından önerilen blok için tahmini bir puan belirlenir. en yüksek final puanı geçerli taş olacaktır.
**Öncelikle Komiteye nasıl katılınır? Aslında L1'de 16 ETH taahhüt etmeniz, **ve rehin işlemi tamamlandıktan sonra 4 L1 bloğu beklemeniz ve ardından Sequencer Committee'ye katılmanız gerekiyor. Sequencer Committee'den çıkmak için L1 kontratındaki Stake fonksiyonunu çağırmanız gerekiyor ve 3 gün sonra katkınızın kalan kısmını geri alabilirsiniz.
O halde, VDF nedir? Doğrulanabilir Gecikme İşlevi, doğrulanabilir bir gecikme işlevidir. Bu matematiksel işlev, katı seri yürütme özelliklerini karşılar. Bazı hesaplama adımlarını gerçekleştirecek ve en azından tahmin edilebilir bir süre tüketecektir. VDF tarafından hesaplanan değeri, tekdüze bir normal dağılımı sağlayan Puan olarak kaydediyoruz.Bu nedenle, Sequencer, VDF Puanını hesapladıktan sonra, yasal teklif sahibi olarak seçilme olasılığını değerlendirebilir. **
Sıralayıcının VDF'si şu şekilde hesaplanır:
Skor = VDF(özel anahtar, genel girişler)
genel girişler = {geçerli blok numarası, randao}
randao, Sıralayıcının gelecekteki tüm blok yüksekliklerinde kendi VDF Puanını önceden hesaplamasını önlemek için kullanılan rastgele bir sayıdır.
Fernet'in tüm süreci temel olarak 3 aşamaya ayrılmıştır:
**Teklif Aşaması:**TEKLİF_PHASE_L1_BLOCKS = 2 Ethereum bloğu (bu aşama 2 L1 bloğu sürecektir)
Bu aşamanın başlangıcında, her Sıralayıcı mevcut blok yüksekliğinde karşılık gelen VDF Puanını hesaplamak için VDF'yi kullanacaktır. Sequencer, VDF Puanının bu kez bir blok oluşturma hakkını kazanacağını düşünürse (Puanın normal bir dağılımı karşıladığını varsayarsak), Tekliften L1'e bir Toplama sözleşmesi sunacaktır. Teklif şunları içerir: önceki L2 bloğuna işaret eden işlem dizisinin karması.
kanıtlanmamış blok: Yalnızca Toplama sözleşmesi Teklifinin blok içerikleri sunulur. Ardından, **Sequencer'ın kanıtlanmamış bloğa karşılık gelen blok içeriklerini ve VDF'nin kanıtını L2 p2p ağına göndermesi gerekir. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 L1 blok (bu faz 50 L1 blok, yaklaşık 10 dakika sürecektir)
Prover, Blok İçeriklerindeki ilgili tüm işlemleri L2 p2p ağından alır ve daha yüksek VDF Puanına sahip bloklar için Kanıt oluşturur. Proof'un inşası aynı zamanda paralel olarak işbirliği yapan birden fazla Provers yöntemini benimser (B52 şemasına benzer).
Bu nedenle, Sequencer'ın birden çok farklı işleme karşılık gelen Kanıtları sonunda bir Blok Kanıtında (VDF Kanıtı dahil) toplaması ve bunu L1'in Toplama sözleşmesine sunması gerekir. Toplama sözleşmesine Blok Kanıtı göndermiş olan herkes Blok İçerikleri gönderebilir.
Sonlandırma: Bloğu Sonlandırmak için bir L1 işlemi göndermek gerekir.Sonlandırılabilecek bir bloğun karşılanması gerekir: Blok İçerikleri ve Blok Kanıtı gönderilir ve işaret edilen önceki blok Sonlandırılmalıdır. Yukarıdaki koşulları karşılama temelinde, en yüksek Puana da sahip olmalısınız.
Ardışık blok üretim mekanizması: Fernet'in bir boru hattı blok üretim mekanizmasını benimsediği belirtilmelidir.Nth bloğunun Proposal aşaması bittiğinde, N+1th bloğunun Proposal aşaması başlar (Aptos ve diğer genel zincirlerin de benzer uygulamaları vardır). Ancak N+1. blok için, L1 Final Block işlemini gönderip Final Block olmak için doğrulamayı geçebilmesi için N. bloğun Finalize edilmesini beklemesi gerekir.
Potansiyel saldırı boyutları: En yüksek VDF Puanına sahip Sıralayıcı, Blok İçeriklerini kasıtlı olarak L2 p2p'de yayınlamazsa, bloğun yeniden düzenlenmesine yol açabilir.
Yeniden düzenlemedeki L2 blok sayısının hesaplanması: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blok
Çözüm: Her L2 yuvası (blok oluşturma zaman dilimi) için yalnızca bir tam aday bloğa sahip olmaktan kaçınmak için amca blok mekanizmasını artırın.
Ademi merkeziyet açısından Fernet'in önemi: Sıralayıcı, Sıralayıcı Komitesine 16 ETH sözü vererek katılır ve giriş eşiği yüksek değildir (ancak düşük değildir). Kanıtlayan herhangi bir rehin gerektirmez, ancak Kanıtlayan Kanıt üretmezse ceza yoktur. Bu temelde B52 şemasının tersidir.
**Aktif Canlılık: **VDF+uncle blok mekanizması her turda birden fazla blok üreticisi olmasını sağlayabildiğinden, genel ağın Canlılığı garanti edilebilir.
**MEV: **MEV hususları en özel olanıdır. Plan, PBS'yi tanıtmayı planlıyor, böylece bir Sıralayıcı olarak yüksek bir VDF Puanı hesapladıktan sonra, daha değerli bir blok inşa etmek için doğrudan bir Blok Oluşturucu bulabilirsiniz.
**Sansür Direnci: **Fernet ayrıca Ethereum ile aynı PBS mekanizmasını benimseyecektir, bu nedenle özünde Fernet'in anti-sansür sorunu Ethereum'un PBS'sininkine eşdeğerdir.