Bạn đã bao giờ muốn tìm hiểu thêm về cách hoạt động của Rollup chưa? Lý thuyết là tốt, nhưng kinh nghiệm thực hành luôn được ưu tiên hơn. Thật không may, các dự án hiện tại không phải lúc nào cũng giúp bạn dễ dàng nhìn thấy những gì đang xảy ra. Đó là lý do tại sao chúng tôi tạo ra BYOR (Build Your Own Rollup). Nó là một bản tổng hợp có chủ quyền với chức năng tối thiểu, tập trung vào việc làm cho mã dễ đọc và dễ hiểu.
Động lực của chúng tôi cho dự án này là để mọi người, cả người ngoài và người trong cuộc, hiểu rõ hơn về những gì các cuộn xung quanh chúng tôi đang thực sự làm. Bạn có thể chơi xung quanh trên BYOR đã triển khai của Holesky hoặc đọc mã nguồn trên GitHub.
BYOR là gì?
Dự án BYOR là phiên bản đơn giản hóa của sovereign rollup. Trái ngược với bằng chứng lạc quan và không có kiến thức về các bản tổng hợp, các bản tổng hợp có chủ quyền không xác nhận nguồn gốc trạng thái trên Ethereum và chỉ dựa vào tính sẵn có của dữ liệu và sự đồng thuận trên Ethereum. Điều này ngăn chặn cầu nối giảm thiểu sự tin cậy giữa L1 và BYOR, nhưng đơn giản hóa rất nhiều mã và lý tưởng cho mục đích giáo dục.
Cơ sở mã bao gồm ba chương trình: hợp đồng thông minh, nút và ví. Khi được triển khai cùng nhau, chúng cho phép người dùng cuối tương tác với mạng. Thật thú vị, trạng thái của mạng được xác định hoàn toàn bởi dữ liệu trên chuỗi, có nghĩa là nhiều nút thực sự có thể chạy. Mỗi nút cũng có thể xuất bản dữ liệu độc lập dưới dạng trình tự trình tự.
Dưới đây là danh sách đầy đủ các tính năng được triển khai trong BYOR:
Phân loại phí
Đăng trạng thái lên L1 và nhận trạng thái từ L1
Loại bỏ các giao dịch không hợp lệ
Kiểm tra số dư tài khoản
Gửi giao dịch
Kiểm tra trạng thái giao dịch
Sử dụng ví
Trong một ứng dụng ví, nó hoạt động như giao diện người dùng của mạng, nơi người dùng có thể gửi giao dịch và kiểm tra trạng thái tài khoản của họ hoặc trạng thái giao dịch. Trên trang đích, bạn sẽ thấy tổng quan cung cấp một số thống kê về trạng thái hiện tại của Rollup, tiếp theo là trạng thái tài khoản của bạn. Nhiều khả năng, chỉ có một nút để kết nối với ví bạn chọn và có tin tức về vòi mã thông báo. Bên dưới, có một thanh tìm kiếm nơi bạn có thể dán địa chỉ hoặc hàm băm giao dịch của ai đó để khám phá trạng thái hiện tại của L2. Cuối cùng, có hai danh sách giao dịch: đầu tiên là danh sách các giao dịch trong mempool L2 và thứ hai là danh sách các giao dịch được công bố cho L1.
Để bắt đầu, hãy sử dụng nút WalletConnect để kết nối ví của bạn. Sau khi kết nối, bạn có thể nhận được thông báo rằng ví của bạn được kết nối sai mạng. Nếu ứng dụng của bạn hỗ trợ chuyển đổi mạng, hãy nhấp vào nút Chuyển mạng để chuyển sang mạng thử nghiệm Holesky. Nếu không, hãy chuyển đổi thủ công.
Giờ đây, bạn có thể gửi mã thông báo cho ai đó bằng cách cung cấp địa chỉ của người nhận, số lượng mã thông báo cần gửi và các khoản phí bắt buộc. Sau khi gửi, ứng dụng ví sẽ nhắc bạn ký tin nhắn. Nếu ký thành công, tin nhắn sẽ được gửi đến nhóm bộ nhớ của nút L2, chờ được xuất bản lên L1. Thời gian cần thiết để một giao dịch được đóng gói thành một bản phát hành hàng loạt có thể khác nhau. Cứ sau 10 giây, nút L2 sẽ kiểm tra nội dung sẽ được xuất bản. Các giao dịch có phí cao hơn được gửi trước, vì vậy nếu bạn chỉ định phí thấp hơn và có nhiều lưu lượng giao dịch, bạn có thể gặp phải thời gian chờ đợi lâu.
Cách thức hoạt động
Sơ đồ kiến trúc tổng hợp ## ngăn xếp công nghệ
Chúng tôi xây dựng từng thành phần bằng các kỹ thuật sau:
Mã BYOR được thiết kế để dễ hiểu bằng cách nhìn vào cơ sở mã. Hãy khám phá cơ sở mã của chúng tôi! Đầu tiên đọc * README.md *, để hiểu cấu trúc dự án, vui lòng đọc tệp * ARCHITECTURE.md *.
Dưới đây là một số điểm nổi bật thú vị từ mã:
Hợp đồng thông minh
SPDX-License-Identifier: MIT
độ vững chắc thực dụng ^0.8.0;
hợp đồng Inputs {
sự kiện BatchAppended(người gửi địa chỉ);
hàm appendBatch(bytes calldata) external {
yêu cầu (msg.sender == tx.origin);
phát ra BatchAppended(msg.sender);
}
}
Đây là hợp đồng thông minh duy nhất cần thiết. Tên của nó xuất phát từ thực tế là các đầu vào được lưu trữ trong các chức năng chuyển đổi trạng thái. Mục đích duy nhất của hợp đồng này là lưu trữ thuận tiện tất cả các giao dịch. Lô được tuần tự hóa được xuất bản lên hợp đồng thông minh này dưới dạng calldata và nó phát ra sự kiện BatchAppended với địa chỉ của nhà xuất bản hàng loạt. Mặc dù chúng ta có thể thiết kế hệ thống để nó xuất bản các giao dịch trực tiếp lên EOA thay vì hợp đồng, dữ liệu có thể dễ dàng được tìm nạp qua JSON-RPC bằng cách phát ra các sự kiện. Yêu cầu duy nhất đối với hợp đồng thông minh này là nó không nên được gọi từ một hợp đồng thông minh khác, mà trực tiếp từ EOA.
Lược đồ cơ sở dữ liệu
TẠO TÀI KHOẢN BẢNG (
văn bản địa chỉ KHÓA CHÍNH KHÔNG NULL,
số nguyên cân bằng MẶC ĐỊNH 0 KHÔNG NULL,
số nguyên nonce DEFAULT 0 NOT NULL
);
TẠO GIAO DỊCH BẢNG (
số nguyên id,
từ văn bản KHÔNG NULL,
để nhắn tin KHÔNG NULL,
số nguyên giá trị KHÔNG NULL,
số nguyên nonce KHÔNG NULL,
số nguyên phí KHÔNG NULL,
feeReceipent văn bản KHÔNG NULL,
Số nguyên l1SubmittedDate KHÔNG NULL,
văn bản băm KHÔNG NULL
KHÓA CHÍNH(từ, nonce)
);
-- Bảng này có một hàng duy nhất
TẠO BẢNG fetcherStates (
Số nguyên chainId KHÓA CHÍNH KHÔNG NULL,
lastFetchedKhối số nguyên DEFAULT 0 NOT NULL
);
Đây là toàn bộ lược đồ cơ sở dữ liệu được sử dụng để lưu trữ thông tin về Rollup. Bạn có thể tự hỏi tại sao chúng ta cần một cơ sở dữ liệu khi tất cả dữ liệu cần thiết được lưu trữ trên L1. Mặc dù điều này là đúng, việc lưu trữ dữ liệu cục bộ có thể tiết kiệm thời gian và tài nguyên bằng cách tránh mua lại trùng lặp. Xử lý tất cả dữ liệu được lưu trữ trong lược đồ này dưới dạng bản ghi nhớ về trạng thái, hàm băm giao dịch và thông tin được tính toán khác.
Bảng fetcherStates được sử dụng để theo dõi khối cuối cùng mà chúng ta đã tìm nạp khi tìm kiếm sự kiện BatchAppended. Điều này rất hữu ích khi nút tắt và khởi động lại; Nó biết nơi để tiếp tục tìm kiếm.
Các chức năng được hiển thị ở trên là trung tâm của cơ chế chuyển đổi trạng thái trong BYOR. Nó giả định rằng giao dịch có thể được thực hiện một cách an toàn, với số dư chính xác và đủ để thực hiện thanh toán được xác định. Do giả định này, không có bước xử lý lỗi hoặc xác thực nào bên trong hàm này. Thay vào đó, các bước này được thực hiện trước khi hàm được gọi. Mỗi trạng thái tài khoản được lưu trữ trong một bản đồ. Nếu một tài khoản chưa tồn tại trong ánh xạ này, nó sẽ được đặt thành giá trị mặc định hiển thị ở đầu danh sách mã. Trong số ba tài khoản được sử dụng, nonce được cập nhật và số dư được phân bổ.
Ký kết giao dịch
Chữ ký giao dịch: Chúng tôi sử dụng tiêu chuẩn EIP-712 để ký dữ liệu đã nhập. Điều này cho phép chúng tôi hiển thị rõ ràng cho người dùng những gì họ đang ký. Như đã trình bày ở trên, khi gửi giao dịch, chúng tôi có thể hiển thị người nhận, số tiền và phí theo cách thân thiện với người dùng.
Sự kiện L1 nhận được
hàm getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const events = getLogs(lastBatchBlock)
const calldata = getCalldata(events)
dấu thời gian const = getTimestamps(sự kiện)
const posters = getTransactionPosters(events)
updateLastFetchedBlock(lastBatchBlock)
Trả lại ZIP (áp phích, dấu thời gian, dữ liệu cuộc gọi)
}
Để tải sự kiện mới, chúng tôi truy xuất tất cả các sự kiện BatchAppended từ khối được tìm nạp cuối cùng từ hợp đồng Đầu vào. Số lượng sự kiện tối đa mà chúng tôi truy xuất là đoạn gần đây nhất hoặc đoạn được tìm nạp cuối cùng cộng với giới hạn kích thước lô. Sau khi truy xuất tất cả các sự kiện, chúng tôi trích xuất dữ liệu cuộc gọi, dấu thời gian và địa chỉ nhà xuất bản từ mỗi giao dịch. Cập nhật khối cuối cùng chúng tôi tìm nạp đến khối cuối cùng chúng tôi đang tìm nạp. Dữ liệu cuộc gọi, dấu thời gian và nhà xuất bản được trích xuất sau đó được đóng gói cùng nhau và trả về từ hàm để xử lý thêm.
Nhóm bộ nhớ và phân loại chi phí của chúng
hàm popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.fee - a.phí))
trả về txPool.splice(0, n)
}
Mempool là một đối tượng quản lý một loạt các giao dịch đã ký. Khía cạnh thú vị nhất là cách nó xác định thứ tự mà các giao dịch được đăng lên L1. Như được hiển thị trong mã ở trên, các giao dịch được sắp xếp theo phí của chúng. Điều này cho phép giá phí trung bình trong hệ thống dao động dựa trên hoạt động trên chuỗi.
Ngay cả khi bạn chỉ định phí cao, các giao dịch vẫn cần tạo trạng thái hợp lệ nếu chúng cần được thêm vào trạng thái hiện tại. Do đó, bạn không thể gửi các giao dịch không hợp lệ chỉ vì phí cao.
BYOR có thực sự mở rộng quy mô Ethereum không?
Optimism và ZK rollup đã xây dựng các hệ thống để chứng minh rằng nguồn gốc trạng thái được công bố phù hợp với các chức năng chuyển đổi trạng thái và dữ liệu mà chúng cam kết, nhưng các bản tổng hợp có chủ quyền thì không. Do đó, việc loại hình tổng hợp này không thể mở rộng quy mô Ethereum thoạt đầu có vẻ phản trực giác. Tuy nhiên, điều này trở nên hợp lý khi chúng tôi nhận ra rằng các loại bản tổng hợp khác chỉ có thể sử dụng L1 để chứng minh rằng gốc trạng thái được công bố là chính xác. Để phân biệt xem dữ liệu của sovereign rollup có chính xác hay không, chúng ta cần chạy một nút L1 cùng với phần mềm bổ sung để chính thức hóa nút L2 để thực hiện các chức năng chuyển đổi trạng thái, do đó tăng tải tính toán.
Triển vọng tương lai
Xây dựng dự án này là một kinh nghiệm học tập tuyệt vời cho chúng tôi và chúng tôi hy vọng bạn cũng sẽ thấy những nỗ lực của chúng tôi có giá trị. Chúng tôi hy vọng sẽ quay lại BYOR trong tương lai và thêm một hệ thống chống gian lận vào đó. Điều này sẽ làm cho nó trở thành một bản tổng hợp thực sự lạc quan và một lần nữa là một bài học về hoạt động bên trong của các hệ thống chúng ta sử dụng hàng ngày.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Xây dựng Bản tổng hợp của riêng bạn - danh sách các dự án BYOR
Biên soạn: Kế hoạch dịch Denlink
Bạn đã bao giờ muốn tìm hiểu thêm về cách hoạt động của Rollup chưa? Lý thuyết là tốt, nhưng kinh nghiệm thực hành luôn được ưu tiên hơn. Thật không may, các dự án hiện tại không phải lúc nào cũng giúp bạn dễ dàng nhìn thấy những gì đang xảy ra. Đó là lý do tại sao chúng tôi tạo ra BYOR (Build Your Own Rollup). Nó là một bản tổng hợp có chủ quyền với chức năng tối thiểu, tập trung vào việc làm cho mã dễ đọc và dễ hiểu.
Động lực của chúng tôi cho dự án này là để mọi người, cả người ngoài và người trong cuộc, hiểu rõ hơn về những gì các cuộn xung quanh chúng tôi đang thực sự làm. Bạn có thể chơi xung quanh trên BYOR đã triển khai của Holesky hoặc đọc mã nguồn trên GitHub.
BYOR là gì?
Dự án BYOR là phiên bản đơn giản hóa của sovereign rollup. Trái ngược với bằng chứng lạc quan và không có kiến thức về các bản tổng hợp, các bản tổng hợp có chủ quyền không xác nhận nguồn gốc trạng thái trên Ethereum và chỉ dựa vào tính sẵn có của dữ liệu và sự đồng thuận trên Ethereum. Điều này ngăn chặn cầu nối giảm thiểu sự tin cậy giữa L1 và BYOR, nhưng đơn giản hóa rất nhiều mã và lý tưởng cho mục đích giáo dục.
Cơ sở mã bao gồm ba chương trình: hợp đồng thông minh, nút và ví. Khi được triển khai cùng nhau, chúng cho phép người dùng cuối tương tác với mạng. Thật thú vị, trạng thái của mạng được xác định hoàn toàn bởi dữ liệu trên chuỗi, có nghĩa là nhiều nút thực sự có thể chạy. Mỗi nút cũng có thể xuất bản dữ liệu độc lập dưới dạng trình tự trình tự.
Dưới đây là danh sách đầy đủ các tính năng được triển khai trong BYOR:
Sử dụng ví
Trong một ứng dụng ví, nó hoạt động như giao diện người dùng của mạng, nơi người dùng có thể gửi giao dịch và kiểm tra trạng thái tài khoản của họ hoặc trạng thái giao dịch. Trên trang đích, bạn sẽ thấy tổng quan cung cấp một số thống kê về trạng thái hiện tại của Rollup, tiếp theo là trạng thái tài khoản của bạn. Nhiều khả năng, chỉ có một nút để kết nối với ví bạn chọn và có tin tức về vòi mã thông báo. Bên dưới, có một thanh tìm kiếm nơi bạn có thể dán địa chỉ hoặc hàm băm giao dịch của ai đó để khám phá trạng thái hiện tại của L2. Cuối cùng, có hai danh sách giao dịch: đầu tiên là danh sách các giao dịch trong mempool L2 và thứ hai là danh sách các giao dịch được công bố cho L1.
Để bắt đầu, hãy sử dụng nút WalletConnect để kết nối ví của bạn. Sau khi kết nối, bạn có thể nhận được thông báo rằng ví của bạn được kết nối sai mạng. Nếu ứng dụng của bạn hỗ trợ chuyển đổi mạng, hãy nhấp vào nút Chuyển mạng để chuyển sang mạng thử nghiệm Holesky. Nếu không, hãy chuyển đổi thủ công.
Giờ đây, bạn có thể gửi mã thông báo cho ai đó bằng cách cung cấp địa chỉ của người nhận, số lượng mã thông báo cần gửi và các khoản phí bắt buộc. Sau khi gửi, ứng dụng ví sẽ nhắc bạn ký tin nhắn. Nếu ký thành công, tin nhắn sẽ được gửi đến nhóm bộ nhớ của nút L2, chờ được xuất bản lên L1. Thời gian cần thiết để một giao dịch được đóng gói thành một bản phát hành hàng loạt có thể khác nhau. Cứ sau 10 giây, nút L2 sẽ kiểm tra nội dung sẽ được xuất bản. Các giao dịch có phí cao hơn được gửi trước, vì vậy nếu bạn chỉ định phí thấp hơn và có nhiều lưu lượng giao dịch, bạn có thể gặp phải thời gian chờ đợi lâu.
Cách thức hoạt động
Chúng tôi xây dựng từng thành phần bằng các kỹ thuật sau:
Mã truy sâu xuống
Mã BYOR được thiết kế để dễ hiểu bằng cách nhìn vào cơ sở mã. Hãy khám phá cơ sở mã của chúng tôi! Đầu tiên đọc * README.md *, để hiểu cấu trúc dự án, vui lòng đọc tệp * ARCHITECTURE.md *.
Dưới đây là một số điểm nổi bật thú vị từ mã:
Hợp đồng thông minh
SPDX-License-Identifier: MIT
độ vững chắc thực dụng ^0.8.0;
hợp đồng Inputs {
sự kiện BatchAppended(người gửi địa chỉ);
hàm appendBatch(bytes calldata) external {
yêu cầu (msg.sender == tx.origin);
phát ra BatchAppended(msg.sender);
}
}
Đây là hợp đồng thông minh duy nhất cần thiết. Tên của nó xuất phát từ thực tế là các đầu vào được lưu trữ trong các chức năng chuyển đổi trạng thái. Mục đích duy nhất của hợp đồng này là lưu trữ thuận tiện tất cả các giao dịch. Lô được tuần tự hóa được xuất bản lên hợp đồng thông minh này dưới dạng calldata và nó phát ra sự kiện BatchAppended với địa chỉ của nhà xuất bản hàng loạt. Mặc dù chúng ta có thể thiết kế hệ thống để nó xuất bản các giao dịch trực tiếp lên EOA thay vì hợp đồng, dữ liệu có thể dễ dàng được tìm nạp qua JSON-RPC bằng cách phát ra các sự kiện. Yêu cầu duy nhất đối với hợp đồng thông minh này là nó không nên được gọi từ một hợp đồng thông minh khác, mà trực tiếp từ EOA.
Lược đồ cơ sở dữ liệu
TẠO TÀI KHOẢN BẢNG (
văn bản địa chỉ KHÓA CHÍNH KHÔNG NULL,
số nguyên cân bằng MẶC ĐỊNH 0 KHÔNG NULL,
số nguyên nonce DEFAULT 0 NOT NULL
);
TẠO GIAO DỊCH BẢNG (
số nguyên id,
từ văn bản KHÔNG NULL,
để nhắn tin KHÔNG NULL,
số nguyên giá trị KHÔNG NULL,
số nguyên nonce KHÔNG NULL,
số nguyên phí KHÔNG NULL,
feeReceipent văn bản KHÔNG NULL,
Số nguyên l1SubmittedDate KHÔNG NULL,
văn bản băm KHÔNG NULL
KHÓA CHÍNH(từ, nonce)
);
-- Bảng này có một hàng duy nhất
TẠO BẢNG fetcherStates (
Số nguyên chainId KHÓA CHÍNH KHÔNG NULL,
lastFetchedKhối số nguyên DEFAULT 0 NOT NULL
);
Đây là toàn bộ lược đồ cơ sở dữ liệu được sử dụng để lưu trữ thông tin về Rollup. Bạn có thể tự hỏi tại sao chúng ta cần một cơ sở dữ liệu khi tất cả dữ liệu cần thiết được lưu trữ trên L1. Mặc dù điều này là đúng, việc lưu trữ dữ liệu cục bộ có thể tiết kiệm thời gian và tài nguyên bằng cách tránh mua lại trùng lặp. Xử lý tất cả dữ liệu được lưu trữ trong lược đồ này dưới dạng bản ghi nhớ về trạng thái, hàm băm giao dịch và thông tin được tính toán khác.
Bảng fetcherStates được sử dụng để theo dõi khối cuối cùng mà chúng ta đã tìm nạp khi tìm kiếm sự kiện BatchAppended. Điều này rất hữu ích khi nút tắt và khởi động lại; Nó biết nơi để tiếp tục tìm kiếm.
Chức năng chuyển đổi trạng thái
const DEFAULT_ACCOUNT = { số dư: 0, nonce: 0 }
hàm uteTransaction(state, tx, feeRecipient) {
const fromAccount = getAccount(state, tx.from, DEFAULT_ACCOUNT)
const toAccount = getAccount(state, tx.to, DEFAULT_ACCOUNT)
Bước 1: Cập nhật nonce
fromAccount.nonce = tx.nonce
Bước 2: Chuyển giá trị
fromAccount.balance -= tx.value
toAccount.balance += tx.value
Bước 3: Thanh toán phí
fromAccount.balance -= tx.fee
feeRecipientAccount.balance += tx.fee
}
Các chức năng được hiển thị ở trên là trung tâm của cơ chế chuyển đổi trạng thái trong BYOR. Nó giả định rằng giao dịch có thể được thực hiện một cách an toàn, với số dư chính xác và đủ để thực hiện thanh toán được xác định. Do giả định này, không có bước xử lý lỗi hoặc xác thực nào bên trong hàm này. Thay vào đó, các bước này được thực hiện trước khi hàm được gọi. Mỗi trạng thái tài khoản được lưu trữ trong một bản đồ. Nếu một tài khoản chưa tồn tại trong ánh xạ này, nó sẽ được đặt thành giá trị mặc định hiển thị ở đầu danh sách mã. Trong số ba tài khoản được sử dụng, nonce được cập nhật và số dư được phân bổ.
Ký kết giao dịch
Sự kiện L1 nhận được
hàm getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const events = getLogs(lastBatchBlock)
const calldata = getCalldata(events)
dấu thời gian const = getTimestamps(sự kiện)
const posters = getTransactionPosters(events)
updateLastFetchedBlock(lastBatchBlock)
Trả lại ZIP (áp phích, dấu thời gian, dữ liệu cuộc gọi)
}
Để tải sự kiện mới, chúng tôi truy xuất tất cả các sự kiện BatchAppended từ khối được tìm nạp cuối cùng từ hợp đồng Đầu vào. Số lượng sự kiện tối đa mà chúng tôi truy xuất là đoạn gần đây nhất hoặc đoạn được tìm nạp cuối cùng cộng với giới hạn kích thước lô. Sau khi truy xuất tất cả các sự kiện, chúng tôi trích xuất dữ liệu cuộc gọi, dấu thời gian và địa chỉ nhà xuất bản từ mỗi giao dịch. Cập nhật khối cuối cùng chúng tôi tìm nạp đến khối cuối cùng chúng tôi đang tìm nạp. Dữ liệu cuộc gọi, dấu thời gian và nhà xuất bản được trích xuất sau đó được đóng gói cùng nhau và trả về từ hàm để xử lý thêm.
Nhóm bộ nhớ và phân loại chi phí của chúng
hàm popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.fee - a.phí))
trả về txPool.splice(0, n)
}
Mempool là một đối tượng quản lý một loạt các giao dịch đã ký. Khía cạnh thú vị nhất là cách nó xác định thứ tự mà các giao dịch được đăng lên L1. Như được hiển thị trong mã ở trên, các giao dịch được sắp xếp theo phí của chúng. Điều này cho phép giá phí trung bình trong hệ thống dao động dựa trên hoạt động trên chuỗi.
Ngay cả khi bạn chỉ định phí cao, các giao dịch vẫn cần tạo trạng thái hợp lệ nếu chúng cần được thêm vào trạng thái hiện tại. Do đó, bạn không thể gửi các giao dịch không hợp lệ chỉ vì phí cao.
BYOR có thực sự mở rộng quy mô Ethereum không?
Optimism và ZK rollup đã xây dựng các hệ thống để chứng minh rằng nguồn gốc trạng thái được công bố phù hợp với các chức năng chuyển đổi trạng thái và dữ liệu mà chúng cam kết, nhưng các bản tổng hợp có chủ quyền thì không. Do đó, việc loại hình tổng hợp này không thể mở rộng quy mô Ethereum thoạt đầu có vẻ phản trực giác. Tuy nhiên, điều này trở nên hợp lý khi chúng tôi nhận ra rằng các loại bản tổng hợp khác chỉ có thể sử dụng L1 để chứng minh rằng gốc trạng thái được công bố là chính xác. Để phân biệt xem dữ liệu của sovereign rollup có chính xác hay không, chúng ta cần chạy một nút L1 cùng với phần mềm bổ sung để chính thức hóa nút L2 để thực hiện các chức năng chuyển đổi trạng thái, do đó tăng tải tính toán.
Triển vọng tương lai
Xây dựng dự án này là một kinh nghiệm học tập tuyệt vời cho chúng tôi và chúng tôi hy vọng bạn cũng sẽ thấy những nỗ lực của chúng tôi có giá trị. Chúng tôi hy vọng sẽ quay lại BYOR trong tương lai và thêm một hệ thống chống gian lận vào đó. Điều này sẽ làm cho nó trở thành một bản tổng hợp thực sự lạc quan và một lần nữa là một bài học về hoạt động bên trong của các hệ thống chúng ta sử dụng hàng ngày.