📢 Gate廣場 #NERO发帖挑战# 秀觀點贏大獎活動火熱開啓!
Gate NERO生態周來襲!發帖秀出NERO項目洞察和活動實用攻略,瓜分30,000NERO!
💰️ 15位優質發帖用戶 * 2,000枚NERO每人
如何參與:
1️⃣ 調研NERO項目
對NERO的基本面、社區治理、發展目標、代幣經濟模型等方面進行研究,分享你對項目的深度研究。
2️⃣ 參與並分享真實體驗
參與NERO生態周相關活動,並曬出你的參與截圖、收益圖或實用教程。可以是收益展示、簡明易懂的新手攻略、小竅門,也可以是行情點位分析,內容詳實優先。
3️⃣ 鼓勵帶新互動
如果你的帖子吸引到他人參與活動,或者有好友評論“已參與/已交易”,將大幅提升你的獲獎概率!
NERO熱門活動(帖文需附以下活動連結):
NERO Chain (NERO) 生態周:Gate 已上線 NERO 現貨交易,爲回饋平台用戶,HODLer Airdrop、Launchpool、CandyDrop、餘幣寶已上線 NERO,邀您體驗。參與攻略見公告:https://www.gate.com/announcements/article/46284
高質量帖子Tips:
教程越詳細、圖片越直觀、互動量越高,獲獎幾率越大!
市場見解獨到、真實參與經歷、有帶新互動者,評選將優先考慮。
帖子需原創,字數不少於250字,且需獲得至少3條有效互動
構建你自己的Rollup——BYOR 專案一覽
編譯:登鏈翻譯計劃
你是否曾經想要深入瞭解 Rollup 的運作原理? 理論很好,但親身實踐經驗總是更可取的。 不幸的是,現有的專案並不總是讓人輕易地查看內部情況。 這就是為什麼我們創建了 BYOR(Build Your Own Rollup:構建你自己的Rollup)。 它是一個具有最小功能的主權 rollup,重點是使代碼易於閱讀和理解。
我們這個項目的動機是讓人們(無論是外部人員還是內部人員)更好地理解我們周圍的 rollup 實際上在做什麼。 你可以在 Holesky 的已部署的BYOR上玩耍,或者閱讀GitHub 上的原始程式碼。
BYOR是什麼?
BYOR 專案是一個簡化版本的主權 rollup。 與樂觀和零知識證明的 rollup 相比,主權 rollup 不會在乙太坊上驗證狀態根,只依賴於乙太坊上的數據可用性和共識。 這樣可以防止 L1 和 BYOR 之間的信任最小化橋,但極大地簡化了代碼,非常適合教育目的。
代碼庫由三個程式組成:智慧合約、節點和錢包。 當它們一起部署時,它們允許最終使用者與網路進行交互。 有趣的是,網路的狀態完全由鏈上數據確定,這意味著實際上可以運行多個節點。 每個節點也可以作為排序器(Sequencer)獨立地發佈數據。
下面是 BYOR 中實現的完整功能清單:
使用錢包
在錢包應用中,它充當網路的前端,使用者可以提交交易,並檢查賬戶的狀態或交易的狀態。 在登陸頁面上,你會看到一個概覽,其中提供了有關 rollup 當前狀態的一些統計資訊,然後是你的賬戶狀態。 很可能,這裡僅有一個按鈕用來連接你選擇的錢包,並有關於代幣水龍頭的消息。 在下面,有一個搜索欄,你可以粘貼某人的位址或交易哈希來探索 L2 的當前狀態。 最後,有兩個交易清單:第一個是 L2 記憶體池中的交易清單,第二個是發佈到 L1 的交易清單。
要開始,請使用 WalletConnect 按鈕連接你的錢包。 連接后,你可能會收到一個通知,提示你的錢包連接到了錯誤的網路。 如果你的應用程式支援網路切換,請點擊「切換網路」按鈕切換到 Holesky 測試網路。 否則,請手動切換。
現在,你可以通過提供接收者的位址、要發送的代幣數量和所需手續費來向某人發送代幣。 發送后,錢包應用程式會提示你簽署消息。 如果成功簽署,消息將被發送到 L2 節點的記憶體池中,等待被發佈到 L1。 交易被捆綁到批次發佈中所需的時間可能會有所不同。 每 10 秒,L2 節點會檢查是否有待發佈的內容。 手續費較高的交易會優先發送,因此如果你指定了較低的手續費並且有大量交易流量,你可能會遇到較長的等待時間。
工作原理
我們使用以下技術構建了每個元件:
代碼深入解析
BYOR 代碼專門設計成通過查看代碼庫就能輕鬆理解。 請隨意探索我們的代碼庫! 首先閱讀README.md,瞭解項目結構請閱讀ARCHITECTURE.md檔。
以下是代碼中的一些有趣亮點:
智能合約
SPDX 許可證標識碼:MIT 編譯指示堅固性 ^0.8.0;
合約輸入 { 事件批處理追加(地址發送方); 函數 appendBatch(bytes calldata) external { require(msg.sender == tx.origin); emit BatchAppended(msg.sender); } }
這是唯一需要的智能合約。 它的名稱源於這個事實:將輸入存儲到狀態轉換函數中。 該合約的唯一目的是為了方便地存儲所有交易。 序列化的批次作為 calldata 發佈到這個智慧合約,並且它會發出一個帶有批次發佈者位址的 BatchAppended 事件。 雖然我們可以設計系統,使其將交易直接發佈到 EOA 而不是合約,但通過發出事件可以輕鬆通過 JSON-RPC 獲取數據。 這個智慧合約的唯一要求是它不應該從另一個智慧合約中調用,而應該直接從 EOA 中調用。
資料庫模式
建立表帳戶 ( 位址文本主鍵不為空, 餘額整數 預設值0不為空, 隨機整數 預設值 0 不為 NULL );
建立表型 ( id整數, 從文本不為空, 到文本不為空, 值整數不為空, 隨機整數不為空, 費用整數不為空, 費用接收文本不為空, l1提交日期整數不為空, 哈希文本不為空 主鍵(從,隨機數) );
-- 此表只有一行 建立表提取程式狀態 ( chainId 整數 主鍵不為空, lastFetchedBlock 整數 DEFAULT 0 NOT NULL );
這是用於存儲關於 Rollup 的資訊的整個資料庫模式。 你可能會想當所有必要的數據都存儲在 L1 上,為什麼我們需要一個資料庫。 雖然這是正確的,但是將數據存儲在本地可以通過避免重複獲取來節省時間和資源。 將在此模式中存儲的所有數據視為狀態、交易哈希和其他計算信息的備忘錄。
fetcherStates 表用於跟蹤我們在搜索 BatchAppended 事件時獲取的最後一個塊。 當節點關閉並重新啟動時,這非常有用; 它知道從哪裡恢復搜索。
狀態轉換函數
常量 DEFAULT_ACCOUNT = { 餘額: 0, 隨機數: 0 }
function uteTransaction(state, tx, feeRecipient) { const fromAccount = getAccount(state, tx.from, DEFAULT_ACCOUNT) const toAccount = getAccount(state, tx.to, DEFAULT_ACCOUNT) 步驟 1 更新隨機數 fromAccount.nonce = tx.nonce 步驟 2 轉移價值 fromAccount.balance -= tx.value 到帳戶.餘額 += tx.值 第三步 支付費用 從帳戶餘額 -= tx.費用 費用收款人帳戶餘額 += tx.費用 }
上面顯示的函數是 BYOR 中狀態轉換機制的核心。 它假設交易可以安全地執行,具有正確的 nonce 和足夠的餘額來進行定義的支出。 由於這個假設,在這個函數內部沒有錯誤處理或驗證步驟。 相反,這些步驟在調用函數之前執行。 每個賬戶狀態都存儲在一個映射中。 如果一個帳戶在這個映射中還不存在,它將被設置為代碼清單頂部可見的預設值。 使用的三個帳戶,nonce 被更新,餘額被分配。
交易簽名
L1 事件獲取
函数 getNewStates() { const lastBatchBlock = getLastBatchBlock() const events = getLogs(lastBatchBlock) const calldata = getCalldata(events) const timestamps = getTimestamps(events) const posters = getTransactionPosters(events) updateLastFetchedBlock(lastBatchBlock) 返回 zip(海報、時間戳、呼叫資料) }
為了獲取新的事件,我們從 Inputs 合約中檢索從上次獲取的區塊開始的所有 BatchAppended 事件。 我們檢索的事件數量最多為最新的區塊或上次獲取的區塊加上批量大小限制。 在檢索所有事件之後,我們從每個交易中提取 calldata、時間戳和發佈者位址。 將我們獲取的最後一個區塊更新為我們正在獲取的最後一個區塊。 然後,將提取的 calldata、時間戳和發行者打包在一起,並從函數中返回以進行進一步處理。
記憶體池及其費用排序
function popNHighestFee(txPool, n) { txPool.sort((a, b) => b.fee - a.fee)) 返回 txPool.splice(0, n) }
記憶體池是一個管理已簽名交易陣列的物件。 最有趣的方面是它如何確定交易被發佈到 L1 的順序。 如上所示的代碼,交易是根據它們的費用進行排序的。 這讓系統中位數費用價格會根據鏈上活動而波動。
即使你指定了高費用,如果它們需要被附加到當前狀態,交易仍然需要產生一個有效的狀態。 因此,你不能僅僅因為費用高就提交無效的交易。
BYOR 是否真正擴展了乙太坊?
樂觀和 ZK rollup 已經建立了系統來證明發佈的狀態根與狀態轉換函數和它們提交的數據是一致的,但主權 rollup 沒有。 因此,這種類型的 rollup 無法擴展乙太坊,這一點可能一開始看起來有些違反直覺。 然而,當我們意識到其他類型的 rollup 可以僅使用 L1 來證明發佈的狀態根是正確的時,這就變得合理了。 要區分主權 rollup 的數據是否正確,我們需要運行一個 L1 節點以及額外的軟體,以形式化 L2 節點來執行狀態轉換函數,從而增加了計算負載。
未來展望
對我們來說,構建這個專案是一次很好的學習經驗,我們希望你也會發現我們的努力有價值。 我們希望將來能夠回到 BYOR,為其添加一個欺詐證明系統。 這將使它成為一個真正的樂觀 rollup,並再次成為我們日常使用的系統內部工作方式的教訓。