Pernahkah Anda ingin mempelajari lebih lanjut tentang cara kerja Rollup? Teorinya bagus, tetapi pengalaman langsung selalu lebih disukai. Sayangnya, proyek yang ada tidak selalu memudahkan untuk melihat apa yang sedang terjadi. Itu sebabnya kami membuat BYOR (Build Your Own Rollup). Ini adalah rollup berdaulat dengan fungsionalitas minimal, dengan fokus pada membuat kode mudah dibaca dan dipahami.
Motivasi kami untuk proyek ini adalah agar orang-orang, baik orang luar maupun orang dalam, untuk lebih memahami apa yang sebenarnya dilakukan oleh rollup di sekitar kita. Anda dapat bermain-main di BYOR yang digunakan Holesky atau membaca kode sumber di GitHub.
Apa itu BYOR?
Proyek BYOR adalah versi sederhana dari rollup berdaulat. Berbeda dengan bukti optimis dan tanpa pengetahuan tentang rollup, rollup berdaulat tidak memvalidasi akar negara pada Ethereum dan hanya mengandalkan ketersediaan data dan konsensus di Ethereum. Ini mencegah jembatan minimalisasi kepercayaan antara L1 dan BYOR, tetapi sangat menyederhanakan kode dan sangat ideal untuk tujuan pendidikan.
Basis kode terdiri dari tiga program: kontrak pintar, node, dan dompet. Ketika digunakan bersama-sama, mereka memungkinkan pengguna akhir untuk berinteraksi dengan jaringan. Menariknya, keadaan jaringan ditentukan sepenuhnya oleh data on-chain, yang berarti bahwa beberapa node benar-benar dapat berjalan. Setiap node juga dapat mempublikasikan data secara independen sebagai sequencer.
Berikut adalah daftar lengkap fitur yang diterapkan di BYOR:
Biaya penyortiran
Posting status ke L1 dan dapatkan status dari L1
Buang transaksi yang tidak valid
Periksa saldo akun
Kirim transaksi
Periksa status transaksi
Gunakan dompet
Dalam aplikasi dompet, ini bertindak sebagai ujung depan jaringan, di mana pengguna dapat mengirimkan transaksi dan memeriksa status akun mereka atau status transaksi. Di halaman landing, Anda akan melihat ringkasan yang menyediakan beberapa statistik tentang status Rollup saat ini, diikuti dengan status akun Anda. Kemungkinan besar, hanya ada satu tombol untuk terhubung ke dompet pilihan Anda dan ada berita tentang faucet token. Di bawah ini, ada bilah pencarian tempat Anda dapat menempelkan alamat seseorang atau hash transaksi untuk menjelajahi keadaan L2 saat ini. Akhirnya, ada dua daftar transaksi: yang pertama adalah daftar transaksi di mempool L2, dan yang kedua adalah daftar transaksi yang diterbitkan ke L1.
Untuk memulai, gunakan tombol WalletConnect untuk menghubungkan dompet Anda. Setelah terhubung, Anda mungkin menerima pemberitahuan bahwa dompet Anda terhubung ke jaringan yang salah. Jika aplikasi Anda mendukung pengalihan jaringan, klik tombol Alihkan Jaringan untuk beralih ke jaringan uji Holesky. Jika tidak, beralihlah secara manual.
Sekarang Anda dapat mengirim token ke seseorang dengan memberikan alamat penerima, jumlah token yang akan dikirim, dan biaya yang diperlukan. Setelah dikirim, aplikasi dompet akan meminta Anda untuk menandatangani pesan. Jika berhasil ditandatangani, pesan dikirim ke kumpulan memori node L2, menunggu untuk dipublikasikan ke L1. Waktu yang diperlukan untuk transaksi yang akan digabungkan ke dalam rilis batch dapat bervariasi. Setiap 10 detik, node L2 memeriksa konten yang akan dipublikasikan. Transaksi dengan biaya lebih tinggi dikirim terlebih dahulu, jadi jika Anda menentukan biaya yang lebih rendah dan memiliki banyak lalu lintas transaksi, Anda mungkin mengalami waktu tunggu yang lama.
Cara kerjanya
Diagram arsitektur rollup ## tumpukan teknologi
Kami membangun setiap komponen menggunakan teknik berikut:
Kode BYOR dirancang agar mudah dipahami dengan melihat basis kode. Jangan ragu untuk menjelajahi basis kode kami! Pertama baca * README.md *, untuk memahami struktur proyek, silakan baca file * ARCHITECTURE.md *.
Berikut adalah beberapa sorotan menarik dari kode:
Kontrak pintar
SPDX-Lisensi-Pengenal: MIT
soliditas pragma ^0.8.0;
Input kontrak {
peristiwa BatchAppended(pengirim alamat);
function appendBatch(bytes calldata) external {
membutuhkan (msg.sender == tx.origin);
memancarkan BatchAppended(msg.sender);
}
}
Ini adalah satu-satunya kontrak pintar yang dibutuhkan. Namanya berasal dari fakta bahwa input disimpan dalam fungsi transisi keadaan. Satu-satunya tujuan kontrak ini adalah untuk menyimpan semua transaksi dengan mudah. Batch berseri dipublikasikan ke kontrak pintar ini sebagai calldata, dan memancarkan peristiwa BatchAppended dengan alamat penerbit batch. Meskipun kami dapat merancang sistem sehingga menerbitkan transaksi langsung ke EOA alih-alih kontrak, data dapat dengan mudah diambil melalui JSON-RPC dengan memancarkan peristiwa. Satu-satunya persyaratan untuk kontrak pintar ini adalah tidak boleh dipanggil dari kontrak pintar lain, tetapi langsung dari EOA.
Skema basis data
BUAT akun TABEL (
teks alamat KUNCI UTAMA TIDAK NULL,
bilangan bulat keseimbangan DEFAULT 0 BUKAN NULL,
bilangan bulat nonce DEFAULT 0 TIDAK NULL
);
BUAT TABEL transaksi (
bilangan bulat id,
dari teks NOT NULL,
ke teks TIDAK NULL,
bilangan bulat nilai NOT NULL,
bilangan bulat nonce TIDAK NULL,
bilangan bulat biaya TIDAK NULL,
feeTeks penerimaan TIDAK NULL,
l1SubmittedDate bilangan bulat NOT NULL,
teks hash TIDAK NULL
KUNCI UTAMA(dari, nonce)
);
-- Tabel ini memiliki satu baris
BUAT TABLE fetcherStates (
chainId integer KUNCI UTAMA BUKAN NULL,
lastFetchedBlock bilangan bulat DEFAULT 0 NOT NULL
);
Ini adalah seluruh skema database yang digunakan untuk menyimpan informasi tentang Rollup. Anda mungkin bertanya-tanya mengapa kita membutuhkan database ketika semua data yang diperlukan disimpan di L1. Meskipun ini benar, menyimpan data secara lokal dapat menghemat waktu dan sumber daya dengan menghindari akuisisi duplikat. Perlakukan semua data yang disimpan dalam skema ini sebagai memo status, hash transaksi, dan informasi terhitung lainnya.
Tabel fetcherStates digunakan untuk melacak blok terakhir yang kita ambil saat mencari peristiwa BatchAppended. Ini berguna ketika node dimatikan dan dimulai ulang; Ia tahu di mana harus melanjutkan pencarian.
Fungsi yang ditunjukkan di atas adalah jantung dari mekanisme transisi negara di BYOR. Ini mengasumsikan bahwa transaksi dapat dieksekusi dengan aman, dengan nonce yang benar dan saldo yang cukup untuk melakukan pembayaran yang ditentukan. Karena asumsi ini, tidak ada penanganan kesalahan atau langkah-langkah validasi dalam fungsi ini. Sebaliknya, langkah-langkah ini dilakukan sebelum fungsi dipanggil. Setiap status akun disimpan di peta. Jika akun belum ada dalam pemetaan ini, akun akan diatur ke nilai default yang terlihat di bagian atas daftar kode. Dari tiga akun yang digunakan, nonce diperbarui dan saldo dialokasikan.
Penandatanganan Transaksi
Tanda Tangan Transaksi: Kami menggunakan standar EIP-712 untuk menandatangani data yang diketik. Ini memungkinkan kami menunjukkan dengan jelas kepada pengguna apa yang mereka tandatangani. Seperti yang ditunjukkan di atas, saat mengirim transaksi, kita dapat menampilkan penerima, jumlah, dan biaya dengan cara yang ramah pengguna.
Acara L1 dapatkan
fungsi getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const peristiwa = getLogs (lastBatchBlock)
const calldata = getCalldata(peristiwa)
stempel waktu const = getTimestamps(events)
const posters = getTransactionPosters(acara)
updateLastFetchedBlock (lastBatchBlock)
Kembalikan Zip (poster, stempel waktu, calldata)
}
Untuk mendapatkan event baru, kita mengambil semua event BatchAppended dari blok terakhir yang diambil dari kontrak Input. Jumlah maksimum peristiwa yang kami ambil adalah potongan terbaru atau potongan terakhir yang diambil ditambah batas ukuran batch. Setelah mengambil semua peristiwa, kami mengekstrak calldata, stempel waktu, dan alamat penerbit dari setiap transaksi. Perbarui blok terakhir yang kita ambil ke blok terakhir yang kita ambil. Data panggilan, stempel waktu, dan penerbit yang diekstrak kemudian dikemas bersama dan dikembalikan dari fungsi untuk diproses lebih lanjut.
Kumpulan memori dan penyortiran biayanya
fungsi popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.fee - a.fee))
mengembalikan txPool.splice(0, n)
}
Mempool adalah objek yang mengelola array transaksi yang ditandatangani. Aspek yang paling menarik adalah bagaimana menentukan urutan transaksi yang diposting ke L1. Seperti yang ditunjukkan pada kode di atas, transaksi diurutkan menurut biayanya. Hal ini memungkinkan harga biaya rata-rata dalam sistem berfluktuasi berdasarkan aktivitas on-chain.
Bahkan jika Anda menentukan biaya tinggi, transaksi masih perlu menghasilkan status yang valid jika perlu ditambahkan ke status saat ini. Oleh karena itu, Anda tidak dapat mengirimkan transaksi yang tidak valid hanya karena biaya tinggi.
Apakah BYOR benar-benar menskalakan Ethereum?
Optimisme dan rollup ZK telah membangun sistem untuk membuktikan bahwa akar negara yang diterbitkan konsisten dengan fungsi transisi negara dan data yang mereka lakukan, tetapi rollup berdaulat tidak. Oleh karena itu, ketidakmampuan jenis rollup ini untuk menskalakan Ethereum mungkin tampak berlawanan dengan intuisi pada awalnya. Namun, ini menjadi masuk akal ketika kita menyadari bahwa jenis rollup lain hanya dapat menggunakan L1 untuk membuktikan bahwa root state yang diterbitkan benar. Untuk membedakan apakah data sovereign rollup benar atau tidak, kita perlu menjalankan node L1 bersama dengan perangkat lunak tambahan untuk memformalkan node L2 untuk melakukan fungsi transisi state, sehingga meningkatkan beban komputasi.
Prospek masa depan
Membangun proyek ini adalah pengalaman belajar yang luar biasa bagi kami, dan kami harap Anda akan menemukan upaya kami yang berharga juga. Kami berharap dapat kembali ke BYOR di masa depan dan menambahkan sistem bukti penipuan ke dalamnya. Ini akan menjadikannya rollup yang benar-benar optimis dan sekali lagi pelajaran dalam cara kerja sistem yang kita gunakan setiap hari.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Buat Rollup Anda sendiri – daftar proyek BYOR
Kompilasi: Rencana terjemahan Denlink
Pernahkah Anda ingin mempelajari lebih lanjut tentang cara kerja Rollup? Teorinya bagus, tetapi pengalaman langsung selalu lebih disukai. Sayangnya, proyek yang ada tidak selalu memudahkan untuk melihat apa yang sedang terjadi. Itu sebabnya kami membuat BYOR (Build Your Own Rollup). Ini adalah rollup berdaulat dengan fungsionalitas minimal, dengan fokus pada membuat kode mudah dibaca dan dipahami.
Motivasi kami untuk proyek ini adalah agar orang-orang, baik orang luar maupun orang dalam, untuk lebih memahami apa yang sebenarnya dilakukan oleh rollup di sekitar kita. Anda dapat bermain-main di BYOR yang digunakan Holesky atau membaca kode sumber di GitHub.
Apa itu BYOR?
Proyek BYOR adalah versi sederhana dari rollup berdaulat. Berbeda dengan bukti optimis dan tanpa pengetahuan tentang rollup, rollup berdaulat tidak memvalidasi akar negara pada Ethereum dan hanya mengandalkan ketersediaan data dan konsensus di Ethereum. Ini mencegah jembatan minimalisasi kepercayaan antara L1 dan BYOR, tetapi sangat menyederhanakan kode dan sangat ideal untuk tujuan pendidikan.
Basis kode terdiri dari tiga program: kontrak pintar, node, dan dompet. Ketika digunakan bersama-sama, mereka memungkinkan pengguna akhir untuk berinteraksi dengan jaringan. Menariknya, keadaan jaringan ditentukan sepenuhnya oleh data on-chain, yang berarti bahwa beberapa node benar-benar dapat berjalan. Setiap node juga dapat mempublikasikan data secara independen sebagai sequencer.
Berikut adalah daftar lengkap fitur yang diterapkan di BYOR:
Gunakan dompet
Dalam aplikasi dompet, ini bertindak sebagai ujung depan jaringan, di mana pengguna dapat mengirimkan transaksi dan memeriksa status akun mereka atau status transaksi. Di halaman landing, Anda akan melihat ringkasan yang menyediakan beberapa statistik tentang status Rollup saat ini, diikuti dengan status akun Anda. Kemungkinan besar, hanya ada satu tombol untuk terhubung ke dompet pilihan Anda dan ada berita tentang faucet token. Di bawah ini, ada bilah pencarian tempat Anda dapat menempelkan alamat seseorang atau hash transaksi untuk menjelajahi keadaan L2 saat ini. Akhirnya, ada dua daftar transaksi: yang pertama adalah daftar transaksi di mempool L2, dan yang kedua adalah daftar transaksi yang diterbitkan ke L1.
Untuk memulai, gunakan tombol WalletConnect untuk menghubungkan dompet Anda. Setelah terhubung, Anda mungkin menerima pemberitahuan bahwa dompet Anda terhubung ke jaringan yang salah. Jika aplikasi Anda mendukung pengalihan jaringan, klik tombol Alihkan Jaringan untuk beralih ke jaringan uji Holesky. Jika tidak, beralihlah secara manual.
Sekarang Anda dapat mengirim token ke seseorang dengan memberikan alamat penerima, jumlah token yang akan dikirim, dan biaya yang diperlukan. Setelah dikirim, aplikasi dompet akan meminta Anda untuk menandatangani pesan. Jika berhasil ditandatangani, pesan dikirim ke kumpulan memori node L2, menunggu untuk dipublikasikan ke L1. Waktu yang diperlukan untuk transaksi yang akan digabungkan ke dalam rilis batch dapat bervariasi. Setiap 10 detik, node L2 memeriksa konten yang akan dipublikasikan. Transaksi dengan biaya lebih tinggi dikirim terlebih dahulu, jadi jika Anda menentukan biaya yang lebih rendah dan memiliki banyak lalu lintas transaksi, Anda mungkin mengalami waktu tunggu yang lama.
Cara kerjanya
Kami membangun setiap komponen menggunakan teknik berikut:
Telusuri kode
Kode BYOR dirancang agar mudah dipahami dengan melihat basis kode. Jangan ragu untuk menjelajahi basis kode kami! Pertama baca * README.md *, untuk memahami struktur proyek, silakan baca file * ARCHITECTURE.md *.
Berikut adalah beberapa sorotan menarik dari kode:
Kontrak pintar
SPDX-Lisensi-Pengenal: MIT
soliditas pragma ^0.8.0;
Input kontrak {
peristiwa BatchAppended(pengirim alamat);
function appendBatch(bytes calldata) external {
membutuhkan (msg.sender == tx.origin);
memancarkan BatchAppended(msg.sender);
}
}
Ini adalah satu-satunya kontrak pintar yang dibutuhkan. Namanya berasal dari fakta bahwa input disimpan dalam fungsi transisi keadaan. Satu-satunya tujuan kontrak ini adalah untuk menyimpan semua transaksi dengan mudah. Batch berseri dipublikasikan ke kontrak pintar ini sebagai calldata, dan memancarkan peristiwa BatchAppended dengan alamat penerbit batch. Meskipun kami dapat merancang sistem sehingga menerbitkan transaksi langsung ke EOA alih-alih kontrak, data dapat dengan mudah diambil melalui JSON-RPC dengan memancarkan peristiwa. Satu-satunya persyaratan untuk kontrak pintar ini adalah tidak boleh dipanggil dari kontrak pintar lain, tetapi langsung dari EOA.
Skema basis data
BUAT akun TABEL (
teks alamat KUNCI UTAMA TIDAK NULL,
bilangan bulat keseimbangan DEFAULT 0 BUKAN NULL,
bilangan bulat nonce DEFAULT 0 TIDAK NULL
);
BUAT TABEL transaksi (
bilangan bulat id,
dari teks NOT NULL,
ke teks TIDAK NULL,
bilangan bulat nilai NOT NULL,
bilangan bulat nonce TIDAK NULL,
bilangan bulat biaya TIDAK NULL,
feeTeks penerimaan TIDAK NULL,
l1SubmittedDate bilangan bulat NOT NULL,
teks hash TIDAK NULL
KUNCI UTAMA(dari, nonce)
);
-- Tabel ini memiliki satu baris
BUAT TABLE fetcherStates (
chainId integer KUNCI UTAMA BUKAN NULL,
lastFetchedBlock bilangan bulat DEFAULT 0 NOT NULL
);
Ini adalah seluruh skema database yang digunakan untuk menyimpan informasi tentang Rollup. Anda mungkin bertanya-tanya mengapa kita membutuhkan database ketika semua data yang diperlukan disimpan di L1. Meskipun ini benar, menyimpan data secara lokal dapat menghemat waktu dan sumber daya dengan menghindari akuisisi duplikat. Perlakukan semua data yang disimpan dalam skema ini sebagai memo status, hash transaksi, dan informasi terhitung lainnya.
Tabel fetcherStates digunakan untuk melacak blok terakhir yang kita ambil saat mencari peristiwa BatchAppended. Ini berguna ketika node dimatikan dan dimulai ulang; Ia tahu di mana harus melanjutkan pencarian.
Fungsi transisi status
const DEFAULT_ACCOUNT = { saldo: 0, nonce: 0 }
function uteTransaction(state, tx, feeRecipient) {
const fromAccount = getAccount (negara, tx.from, DEFAULT_ACCOUNT)
const toAccount = getAccount(negara bagian, tx.to, DEFAULT_ACCOUNT)
Langkah 1: Perbarui nonce
dariAccount.nonce = tx.nonce
Langkah 2: Transfer nilai
dariAccount.balance -= tx.value
toAccount.balance += tx.value
Langkah 3: Bayar biaya
fromAccount.balance -= tx.fee
feeRecipientAccount.balance += tx.fee
}
Fungsi yang ditunjukkan di atas adalah jantung dari mekanisme transisi negara di BYOR. Ini mengasumsikan bahwa transaksi dapat dieksekusi dengan aman, dengan nonce yang benar dan saldo yang cukup untuk melakukan pembayaran yang ditentukan. Karena asumsi ini, tidak ada penanganan kesalahan atau langkah-langkah validasi dalam fungsi ini. Sebaliknya, langkah-langkah ini dilakukan sebelum fungsi dipanggil. Setiap status akun disimpan di peta. Jika akun belum ada dalam pemetaan ini, akun akan diatur ke nilai default yang terlihat di bagian atas daftar kode. Dari tiga akun yang digunakan, nonce diperbarui dan saldo dialokasikan.
Penandatanganan Transaksi
Acara L1 dapatkan
fungsi getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const peristiwa = getLogs (lastBatchBlock)
const calldata = getCalldata(peristiwa)
stempel waktu const = getTimestamps(events)
const posters = getTransactionPosters(acara)
updateLastFetchedBlock (lastBatchBlock)
Kembalikan Zip (poster, stempel waktu, calldata)
}
Untuk mendapatkan event baru, kita mengambil semua event BatchAppended dari blok terakhir yang diambil dari kontrak Input. Jumlah maksimum peristiwa yang kami ambil adalah potongan terbaru atau potongan terakhir yang diambil ditambah batas ukuran batch. Setelah mengambil semua peristiwa, kami mengekstrak calldata, stempel waktu, dan alamat penerbit dari setiap transaksi. Perbarui blok terakhir yang kita ambil ke blok terakhir yang kita ambil. Data panggilan, stempel waktu, dan penerbit yang diekstrak kemudian dikemas bersama dan dikembalikan dari fungsi untuk diproses lebih lanjut.
Kumpulan memori dan penyortiran biayanya
fungsi popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.fee - a.fee))
mengembalikan txPool.splice(0, n)
}
Mempool adalah objek yang mengelola array transaksi yang ditandatangani. Aspek yang paling menarik adalah bagaimana menentukan urutan transaksi yang diposting ke L1. Seperti yang ditunjukkan pada kode di atas, transaksi diurutkan menurut biayanya. Hal ini memungkinkan harga biaya rata-rata dalam sistem berfluktuasi berdasarkan aktivitas on-chain.
Bahkan jika Anda menentukan biaya tinggi, transaksi masih perlu menghasilkan status yang valid jika perlu ditambahkan ke status saat ini. Oleh karena itu, Anda tidak dapat mengirimkan transaksi yang tidak valid hanya karena biaya tinggi.
Apakah BYOR benar-benar menskalakan Ethereum?
Optimisme dan rollup ZK telah membangun sistem untuk membuktikan bahwa akar negara yang diterbitkan konsisten dengan fungsi transisi negara dan data yang mereka lakukan, tetapi rollup berdaulat tidak. Oleh karena itu, ketidakmampuan jenis rollup ini untuk menskalakan Ethereum mungkin tampak berlawanan dengan intuisi pada awalnya. Namun, ini menjadi masuk akal ketika kita menyadari bahwa jenis rollup lain hanya dapat menggunakan L1 untuk membuktikan bahwa root state yang diterbitkan benar. Untuk membedakan apakah data sovereign rollup benar atau tidak, kita perlu menjalankan node L1 bersama dengan perangkat lunak tambahan untuk memformalkan node L2 untuk melakukan fungsi transisi state, sehingga meningkatkan beban komputasi.
Prospek masa depan
Membangun proyek ini adalah pengalaman belajar yang luar biasa bagi kami, dan kami harap Anda akan menemukan upaya kami yang berharga juga. Kami berharap dapat kembali ke BYOR di masa depan dan menambahkan sistem bukti penipuan ke dalamnya. Ini akan menjadikannya rollup yang benar-benar optimis dan sekali lagi pelajaran dalam cara kerja sistem yang kita gunakan setiap hari.