Rollup'ın nasıl çalıştığı hakkında daha fazla bilgi edinmek istediniz mi? Teori iyidir, ancak uygulamalı deneyim her zaman tercih edilir. Ne yazık ki, mevcut projeler neler olup bittiğini görmeyi her zaman kolaylaştırmaz. Bu yüzden BYOR'u (Kendi Paketinizi Oluşturun) yarattık. Kodun okunmasını ve anlaşılmasını kolaylaştırmaya odaklanan, minimum işlevselliğe sahip bağımsız bir toplamadır.
Bu proje için motivasyonumuz, hem dışarıdan hem de içeriden insanların, etrafımızdaki toplamaların gerçekte ne yaptığını daha iyi anlamalarıdır. Holesky'nin konuşlandırılmış BYOR'unda oynayabilir veya GitHub'daki kaynak kodunu okuyabilirsiniz.
BYOR nedir?
BYOR projesi, bağımsız toplamanın basitleştirilmiş bir sürümüdür. Rollup'ların iyimser ve sıfır bilgi kanıtlarının aksine, bağımsız rollup'lar Ethereum'daki durum köklerini doğrulamaz ve yalnızca Ethereum'daki veri kullanılabilirliğine ve fikir birliğine dayanır. Bu, L1 ve BYOR arasındaki güven minimizasyonu köprülerini önler, ancak kodu büyük ölçüde basitleştirir ve eğitim amaçları için idealdir.
Kod tabanı üç programdan oluşur: akıllı sözleşmeler, düğümler ve cüzdanlar. Birlikte dağıtıldıklarında, son kullanıcıların ağ ile etkileşime girmesine izin verirler. İlginç bir şekilde, ağın durumu tamamen zincir üstü veriler tarafından belirlenir, bu da birden fazla düğümün gerçekten çalışabileceği anlamına gelir. Her düğüm ayrıca verileri bağımsız olarak bir sıralayıcı olarak yayınlayabilir.
BYOR'da uygulanan özelliklerin tam listesi:
Ücret sıralaması
Durumu L1'e gönderin ve L1'den durumu alın
Geçersiz işlemleri atın
Hesap bakiyesini kontrol edin
İşlemleri gönder
İşlem durumunu kontrol edin
Cüzdanı kullanın
Bir cüzdan uygulamasında, kullanıcıların işlemleri gönderebilecekleri ve hesaplarının durumunu veya işlemlerin durumunu kontrol edebilecekleri ağın ön ucu görevi görür. Açılış sayfasında, Toplama'nın mevcut durumu hakkında bazı istatistikler ve ardından hesabınızın durumu hakkında bazı istatistikler sağlayan bir genel bakış görürsünüz. Büyük olasılıkla, seçtiğiniz cüzdana bağlanmak için yalnızca bir düğme vardır ve token musluğu hakkında haberler vardır. Aşağıda, L2'nin mevcut durumunu keşfetmek için birinin adresini veya işlem hash'ini yapıştırabileceğiniz bir arama çubuğu vardır. Son olarak, iki işlem listesi vardır: Birincisi L2 mempool'undaki işlemlerin listesi, ikincisi ise L1'de yayınlanan işlemlerin listesidir.
Başlamak için, cüzdanınızı bağlamak için WalletConnect düğmesini kullanın. Bağlandıktan sonra, cüzdanınızın yanlış ağa bağlı olduğuna dair bir bildirim alabilirsiniz. Uygulamanız ağ anahtarlamayı destekliyorsa, Holesky test ağına geçmek için Ağ Değiştir düğmesine tıklayın. Aksi takdirde, manuel olarak geçiş yapın.
Artık alıcının adresini, gönderilecek jeton sayısını ve gerekli ücretleri sağlayarak birine jeton gönderebilirsiniz. Gönderildikten sonra, cüzdan uygulaması sizden mesajı imzalamanızı isteyecektir. Başarılı bir şekilde imzalanırsa, ileti L2 düğümünün bellek havuzuna gönderilir ve L1'de yayımlanmayı bekler. Bir işlemin toplu sürümde paketlenmesi için geçen süre değişebilir. Her 10 saniyede bir, L2 düğümü yayınlanacak içeriği kontrol eder. Daha yüksek ücretli işlemler önce gönderilir, bu nedenle daha düşük ücretler belirtirseniz ve çok fazla işlem trafiğiniz varsa, uzun bekleme süreleri yaşayabilirsiniz.
Nasıl çalışır?
Toplama mimarisi diyagramı ## teknoloji yığını
Her bileşeni aşağıdaki teknikleri kullanarak oluşturduk:
BYOR kodu, kod tabanına bakılarak kolayca anlaşılabilecek şekilde tasarlanmıştır. Kod tabanımızı keşfetmekten çekinmeyin! Önce README.md'yi okuyun, proje yapısını anlamak için lütfen ARCHITECTURE.md dosyasını okuyun.
İşte koddan bazı ilginç noktalar:
Akıllı sözleşmeler
SPDX-Lisans Tanımlayıcısı: MIT
pragma sağlamlığı ^0.8.0;
sözleşme Girdileri {
olay BatchAppended(adres gönderen);
function appendBatch(bytes calldata) external {
require(msg.sender == tx.origin);
emit BatchAppended(msg.sender);
}
}
Bu, ihtiyaç duyulan tek akıllı sözleşmedir. Adı, girdilerin durum geçiş fonksiyonlarında saklanması gerçeğinden kaynaklanmaktadır. Bu sözleşmenin tek amacı, tüm işlemleri uygun bir şekilde saklamaktır. Serileştirilmiş toplu iş bu akıllı sözleşmede çağrı verisi olarak yayımlanır ve toplu iş yayımcısının adresiyle bir BatchAppended olayı yayar. Sistemi, işlemleri sözleşmeler yerine doğrudan EOA'ya yayınlayacak şekilde tasarlayabilirken, veriler olaylar yayarak JSON-RPC aracılığıyla kolayca getirilebilir. Bu akıllı sözleşme için tek şart, başka bir akıllı sözleşmeden değil, doğrudan EOA'dan çağrılması gerektiğidir.
-- Bu tabloda tek satır var
CREATE TABLE fetcherStates (
chainId tamsayı BİRİNCİL ANAHTAR NULL DEĞİL,
lastFetchedBlock tamsayı VARSAYILAN 0 NULL DEĞİL
);
Bu, Toplama hakkında bilgi depolamak için kullanılan veritabanı şemasının tamamıdır. Gerekli tüm veriler L1'de saklanırken neden bir veritabanına ihtiyacımız olduğunu merak ediyor olabilirsiniz. Bu doğru olsa da, verileri yerel olarak depolamak, yinelenen alımları önleyerek zamandan ve kaynaklardan tasarruf sağlayabilir. Bu şemada depolanan tüm verileri durum notları, işlem karmaları ve diğer hesaplanan bilgiler olarak değerlendirin.
fetcherStates tablosu, BatchAppended olayını ararken getirdiğimiz son bloğu izlemek için kullanılır. Bu, düğüm kapandığında ve yeniden başlatıldığında kullanışlıdır; Aramaya nerede devam edeceğini bilir.
Yukarıda gösterilen fonksiyonlar, BYOR'daki durum geçiş mekanizmasının merkezinde yer alır. İşlemin, tanımlanan ödemeyi yapmak için doğru nonce ve yeterli bakiye ile güvenli bir şekilde gerçekleştirilebileceğini varsayar. Bu varsayım nedeniyle, bu işlevin içinde hata işleme veya doğrulama adımları yoktur. Bunun yerine, bu adımlar işlev çağrılmadan önce gerçekleştirilir. Her hesap durumu bir haritada depolanır. Bu eşlemede bir hesap yoksa, kod listesinin en üstünde görünen varsayılan değere ayarlanır. Kullanılan üç hesaptan nonce güncellenir ve bakiye tahsis edilir.
İşlem İmzalama
İşlem İmzası: Yazılan verileri imzalamak için EIP-712 standardını kullanıyoruz. Bu, kullanıcılara neyi imzaladıklarını net bir şekilde göstermemizi sağlar. Yukarıda gösterildiği gibi, bir işlem gönderirken alıcıyı, tutarı ve ücreti kullanıcı dostu bir şekilde görüntüleyebiliriz.
L1 olayı olsun
function getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const olayları = getLogs(lastBatchBlock)
const çağrı verisi = getCalldata(olaylar)
const zaman damgaları = getTimestamps(olaylar)
const posters = getTransactionPosters(events)
updateLastFetchedBlock(lastBatchBlock)
Return Zip (posterler, zaman damgaları, çağrı verileri)
}
Yeni olayı almak için, Girdiler sözleşmesinden son getirilen bloktan tüm BatchAppended olaylarını alırız. Aldığımız maksimum olay sayısı, en son öbek veya son getirilen öbek artı toplu iş boyutu sınırıdır. Tüm olayları aldıktan sonra, her işlemden çağrı verilerini, zaman damgasını ve yayıncı adresini çıkarırız. Getirdiğimiz son bloğu, getirdiğimiz son bloğa güncelleyin. Ayıklanan çağrı verileri, zaman damgası ve yayımcı daha sonra birlikte paketlenir ve daha fazla işlenmek üzere işlevden döndürülür.
Bellek havuzları ve maliyet sıralaması
function popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.ücret - a.ücret))
return txPool.splice(0, n)
}
Mempool, bir dizi imzalı işlemi yöneten bir nesnedir. En ilginç yönü, işlemlerin L1'e kaydedilme sırasını nasıl belirlediğidir. Yukarıdaki kodda gösterildiği gibi, işlemler ücretlerine göre sıralanır. Bu, sistemdeki medyan ücret fiyatının zincir içi aktiviteye bağlı olarak dalgalanmasına izin verir.
Yüksek ücretler belirtseniz bile, işlemlerin geçerli duruma eklenmesi gerekiyorsa yine de geçerli bir durum oluşturması gerekir. Bu nedenle, yüksek ücretler nedeniyle geçersiz işlemler gönderemezsiniz.
BYOR gerçekten Ethereum'u ölçeklendiriyor mu?
İyimserlik ve ZK toplaması, yayınlanan durum köklerinin durum geçiş işlevleri ve işledikleri verilerle tutarlı olduğunu kanıtlamak için sistemler oluşturmuştur, ancak bağımsız toplamalar bunu yapmaz. Bu nedenle, bu tür bir toplamanın Ethereum'u ölçeklendirememesi ilk başta mantıksız görünebilir. Ancak, diğer toplama türlerinin yayımlanan durum kökünün doğru olduğunu kanıtlamak için yalnızca L1'i kullanabileceğini fark ettiğimizde bu makul hale gelir. Bağımsız toplamanın verilerinin doğru olup olmadığını ayırt etmek için, durum geçiş işlevlerini gerçekleştirmek üzere L2 düğümünü resmileştirmek için ek yazılımla birlikte bir L1 düğümü çalıştırmamız ve böylece hesaplama yükünü artırmamız gerekir.
Geleceğe bakış
Bu projeyi inşa etmek bizim için harika bir öğrenme deneyimiydi ve umarız siz de çabalarımızı değerli bulursunuz. Gelecekte BYOR'a geri dönmeyi ve ona bir sahtekarlık kanıtı sistemi eklemeyi umuyoruz. Bu, onu gerçekten iyimser bir toparlama ve bir kez daha her gün kullandığımız sistemlerin iç işleyişinde bir ders haline getirecektir.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Kendi Toplamanızı oluşturun – BYOR projelerinin listesi
Derleme: Denlink çeviri planı
Rollup'ın nasıl çalıştığı hakkında daha fazla bilgi edinmek istediniz mi? Teori iyidir, ancak uygulamalı deneyim her zaman tercih edilir. Ne yazık ki, mevcut projeler neler olup bittiğini görmeyi her zaman kolaylaştırmaz. Bu yüzden BYOR'u (Kendi Paketinizi Oluşturun) yarattık. Kodun okunmasını ve anlaşılmasını kolaylaştırmaya odaklanan, minimum işlevselliğe sahip bağımsız bir toplamadır.
Bu proje için motivasyonumuz, hem dışarıdan hem de içeriden insanların, etrafımızdaki toplamaların gerçekte ne yaptığını daha iyi anlamalarıdır. Holesky'nin konuşlandırılmış BYOR'unda oynayabilir veya GitHub'daki kaynak kodunu okuyabilirsiniz.
BYOR nedir?
BYOR projesi, bağımsız toplamanın basitleştirilmiş bir sürümüdür. Rollup'ların iyimser ve sıfır bilgi kanıtlarının aksine, bağımsız rollup'lar Ethereum'daki durum köklerini doğrulamaz ve yalnızca Ethereum'daki veri kullanılabilirliğine ve fikir birliğine dayanır. Bu, L1 ve BYOR arasındaki güven minimizasyonu köprülerini önler, ancak kodu büyük ölçüde basitleştirir ve eğitim amaçları için idealdir.
Kod tabanı üç programdan oluşur: akıllı sözleşmeler, düğümler ve cüzdanlar. Birlikte dağıtıldıklarında, son kullanıcıların ağ ile etkileşime girmesine izin verirler. İlginç bir şekilde, ağın durumu tamamen zincir üstü veriler tarafından belirlenir, bu da birden fazla düğümün gerçekten çalışabileceği anlamına gelir. Her düğüm ayrıca verileri bağımsız olarak bir sıralayıcı olarak yayınlayabilir.
BYOR'da uygulanan özelliklerin tam listesi:
Cüzdanı kullanın
Bir cüzdan uygulamasında, kullanıcıların işlemleri gönderebilecekleri ve hesaplarının durumunu veya işlemlerin durumunu kontrol edebilecekleri ağın ön ucu görevi görür. Açılış sayfasında, Toplama'nın mevcut durumu hakkında bazı istatistikler ve ardından hesabınızın durumu hakkında bazı istatistikler sağlayan bir genel bakış görürsünüz. Büyük olasılıkla, seçtiğiniz cüzdana bağlanmak için yalnızca bir düğme vardır ve token musluğu hakkında haberler vardır. Aşağıda, L2'nin mevcut durumunu keşfetmek için birinin adresini veya işlem hash'ini yapıştırabileceğiniz bir arama çubuğu vardır. Son olarak, iki işlem listesi vardır: Birincisi L2 mempool'undaki işlemlerin listesi, ikincisi ise L1'de yayınlanan işlemlerin listesidir.
Başlamak için, cüzdanınızı bağlamak için WalletConnect düğmesini kullanın. Bağlandıktan sonra, cüzdanınızın yanlış ağa bağlı olduğuna dair bir bildirim alabilirsiniz. Uygulamanız ağ anahtarlamayı destekliyorsa, Holesky test ağına geçmek için Ağ Değiştir düğmesine tıklayın. Aksi takdirde, manuel olarak geçiş yapın.
Artık alıcının adresini, gönderilecek jeton sayısını ve gerekli ücretleri sağlayarak birine jeton gönderebilirsiniz. Gönderildikten sonra, cüzdan uygulaması sizden mesajı imzalamanızı isteyecektir. Başarılı bir şekilde imzalanırsa, ileti L2 düğümünün bellek havuzuna gönderilir ve L1'de yayımlanmayı bekler. Bir işlemin toplu sürümde paketlenmesi için geçen süre değişebilir. Her 10 saniyede bir, L2 düğümü yayınlanacak içeriği kontrol eder. Daha yüksek ücretli işlemler önce gönderilir, bu nedenle daha düşük ücretler belirtirseniz ve çok fazla işlem trafiğiniz varsa, uzun bekleme süreleri yaşayabilirsiniz.
Nasıl çalışır?
Her bileşeni aşağıdaki teknikleri kullanarak oluşturduk:
Kod detayına gitme
BYOR kodu, kod tabanına bakılarak kolayca anlaşılabilecek şekilde tasarlanmıştır. Kod tabanımızı keşfetmekten çekinmeyin! Önce README.md'yi okuyun, proje yapısını anlamak için lütfen ARCHITECTURE.md dosyasını okuyun.
İşte koddan bazı ilginç noktalar:
Akıllı sözleşmeler
SPDX-Lisans Tanımlayıcısı: MIT
pragma sağlamlığı ^0.8.0;
sözleşme Girdileri {
olay BatchAppended(adres gönderen);
function appendBatch(bytes calldata) external {
require(msg.sender == tx.origin);
emit BatchAppended(msg.sender);
}
}
Bu, ihtiyaç duyulan tek akıllı sözleşmedir. Adı, girdilerin durum geçiş fonksiyonlarında saklanması gerçeğinden kaynaklanmaktadır. Bu sözleşmenin tek amacı, tüm işlemleri uygun bir şekilde saklamaktır. Serileştirilmiş toplu iş bu akıllı sözleşmede çağrı verisi olarak yayımlanır ve toplu iş yayımcısının adresiyle bir BatchAppended olayı yayar. Sistemi, işlemleri sözleşmeler yerine doğrudan EOA'ya yayınlayacak şekilde tasarlayabilirken, veriler olaylar yayarak JSON-RPC aracılığıyla kolayca getirilebilir. Bu akıllı sözleşme için tek şart, başka bir akıllı sözleşmeden değil, doğrudan EOA'dan çağrılması gerektiğidir.
Veritabanı şeması
TABLO hesapları oluşturun (
adres metni BİRİNCİL ANAHTAR NULL DEĞİL,
bakiye tamsayı VARSAYILAN 0 NULL DEĞİL,
nonce tamsayı DEFAULT 0 NOT NULL
);
TABLO OLUŞTUR işlemleri (
kimlik tamsayısı,
metinden NULL DEĞİL,
NULL DEĞİL metnine,
değer tamsayı NULL DEĞİL,
nonce tamsayı NULL DEĞİL,
ücret tamsayı NULL DEĞİL,
feeReceipent metni NULL DEĞİL,
l1SubmittedDate tamsayı NULL DEĞİL,
karma metin NULL DEĞİL
BİRİNCİL ANAHTAR(kimden, nonce)
);
-- Bu tabloda tek satır var
CREATE TABLE fetcherStates (
chainId tamsayı BİRİNCİL ANAHTAR NULL DEĞİL,
lastFetchedBlock tamsayı VARSAYILAN 0 NULL DEĞİL
);
Bu, Toplama hakkında bilgi depolamak için kullanılan veritabanı şemasının tamamıdır. Gerekli tüm veriler L1'de saklanırken neden bir veritabanına ihtiyacımız olduğunu merak ediyor olabilirsiniz. Bu doğru olsa da, verileri yerel olarak depolamak, yinelenen alımları önleyerek zamandan ve kaynaklardan tasarruf sağlayabilir. Bu şemada depolanan tüm verileri durum notları, işlem karmaları ve diğer hesaplanan bilgiler olarak değerlendirin.
fetcherStates tablosu, BatchAppended olayını ararken getirdiğimiz son bloğu izlemek için kullanılır. Bu, düğüm kapandığında ve yeniden başlatıldığında kullanışlıdır; Aramaya nerede devam edeceğini bilir.
Durum geçiş fonksiyonları
sabit DEFAULT_ACCOUNT = { denge: 0, nonce: 0 }
function uteTransaction(state, tx, feeRecipient) {
const fromAccount = getAccount(state, tx.from, DEFAULT_ACCOUNT)
const toAccount = getAccount(eyalet, tx.to, DEFAULT_ACCOUNT)
fromAccount.nonce = tx.nonce
fromAccount.balance -= tx.value
toAccount.balance += tx.value
fromAccount.balance -= tx.fee
feeRecipientAccount.balance += tx.fee
}
Yukarıda gösterilen fonksiyonlar, BYOR'daki durum geçiş mekanizmasının merkezinde yer alır. İşlemin, tanımlanan ödemeyi yapmak için doğru nonce ve yeterli bakiye ile güvenli bir şekilde gerçekleştirilebileceğini varsayar. Bu varsayım nedeniyle, bu işlevin içinde hata işleme veya doğrulama adımları yoktur. Bunun yerine, bu adımlar işlev çağrılmadan önce gerçekleştirilir. Her hesap durumu bir haritada depolanır. Bu eşlemede bir hesap yoksa, kod listesinin en üstünde görünen varsayılan değere ayarlanır. Kullanılan üç hesaptan nonce güncellenir ve bakiye tahsis edilir.
İşlem İmzalama
L1 olayı olsun
function getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const olayları = getLogs(lastBatchBlock)
const çağrı verisi = getCalldata(olaylar)
const zaman damgaları = getTimestamps(olaylar)
const posters = getTransactionPosters(events)
updateLastFetchedBlock(lastBatchBlock)
Return Zip (posterler, zaman damgaları, çağrı verileri)
}
Yeni olayı almak için, Girdiler sözleşmesinden son getirilen bloktan tüm BatchAppended olaylarını alırız. Aldığımız maksimum olay sayısı, en son öbek veya son getirilen öbek artı toplu iş boyutu sınırıdır. Tüm olayları aldıktan sonra, her işlemden çağrı verilerini, zaman damgasını ve yayıncı adresini çıkarırız. Getirdiğimiz son bloğu, getirdiğimiz son bloğa güncelleyin. Ayıklanan çağrı verileri, zaman damgası ve yayımcı daha sonra birlikte paketlenir ve daha fazla işlenmek üzere işlevden döndürülür.
Bellek havuzları ve maliyet sıralaması
function popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.ücret - a.ücret))
return txPool.splice(0, n)
}
Mempool, bir dizi imzalı işlemi yöneten bir nesnedir. En ilginç yönü, işlemlerin L1'e kaydedilme sırasını nasıl belirlediğidir. Yukarıdaki kodda gösterildiği gibi, işlemler ücretlerine göre sıralanır. Bu, sistemdeki medyan ücret fiyatının zincir içi aktiviteye bağlı olarak dalgalanmasına izin verir.
Yüksek ücretler belirtseniz bile, işlemlerin geçerli duruma eklenmesi gerekiyorsa yine de geçerli bir durum oluşturması gerekir. Bu nedenle, yüksek ücretler nedeniyle geçersiz işlemler gönderemezsiniz.
BYOR gerçekten Ethereum'u ölçeklendiriyor mu?
İyimserlik ve ZK toplaması, yayınlanan durum köklerinin durum geçiş işlevleri ve işledikleri verilerle tutarlı olduğunu kanıtlamak için sistemler oluşturmuştur, ancak bağımsız toplamalar bunu yapmaz. Bu nedenle, bu tür bir toplamanın Ethereum'u ölçeklendirememesi ilk başta mantıksız görünebilir. Ancak, diğer toplama türlerinin yayımlanan durum kökünün doğru olduğunu kanıtlamak için yalnızca L1'i kullanabileceğini fark ettiğimizde bu makul hale gelir. Bağımsız toplamanın verilerinin doğru olup olmadığını ayırt etmek için, durum geçiş işlevlerini gerçekleştirmek üzere L2 düğümünü resmileştirmek için ek yazılımla birlikte bir L1 düğümü çalıştırmamız ve böylece hesaplama yükünü artırmamız gerekir.
Geleceğe bakış
Bu projeyi inşa etmek bizim için harika bir öğrenme deneyimiydi ve umarız siz de çabalarımızı değerli bulursunuz. Gelecekte BYOR'a geri dönmeyi ve ona bir sahtekarlık kanıtı sistemi eklemeyi umuyoruz. Bu, onu gerçekten iyimser bir toparlama ve bir kez daha her gün kullandığımız sistemlerin iç işleyişinde bir ders haline getirecektir.