Vitalik: Phân tích lược đồ mở rộng của Rollups - sharding dữ liệu
Chỉnh sửa: Southwind
Vitalik Buterin, Đồng sáng lập Ethereum
Chỉnh sửa: Southwind
Đối với Ethereum, Rollup là giải pháp khả năng mở rộng đáng tin cậy duy nhất trong ngắn hạn và trung hạn và có thể trong dài hạn. Phí giao dịch trên Ethereum L1 đã ở mức cao trong vài tháng và giờ đây, việc thực hiện bất kỳ hành động nào cần thiết để giúp chuyển toàn bộ hệ sinh thái sang Rollups thậm chí còn cấp bách hơn. Rollup đã giảm phí đáng kể cho nhiều người dùng Ethereum: trang web l2fees.info thường cho thấy mạng Optimism và Arbitrum rẻ hơn khoảng 3-8 lần so với chính lớp cơ sở Ethereum, trong khi zk-Rollups nén dữ liệu tốt hơn và có thể tránh bao gồm cả chữ ký, vì vậy phí của nó thấp hơn khoảng 40-100 lần so với lớp cơ sở Ethereum.
Tuy nhiên, ngay cả những khoản phí (trong Tổng số) này cũng quá đắt đối với nhiều người dùng. Trong một thời gian dài, việc phân tách dữ liệu (data sharding) đã được coi là giải pháp cho sự thiếu hụt lâu dài của Rollup ở dạng hiện tại và data sharding được kỳ vọng sẽ bổ sung thêm khoảng 1-2MB/s không gian dữ liệu dành riêng cho Rollup trên Chuỗi Ethereum. Bài viết này mô tả lộ trình thực tế để triển khai giải pháp, mở khóa dung lượng dữ liệu cho Rollup nhanh nhất có thể, đồng thời bổ sung thêm dung lượng và bảo mật theo thời gian.
Bước 1: Mở rộng calldata giao dịchTổng số hiện tại sử dụng calldata giao dịch. Do đó, nếu chúng ta muốn tăng dung lượng của Rollup và giảm chi phí trong thời gian ngắn mà không yêu cầu bất kỳ công việc bổ sung nào của các nhóm Rollups khác nhau, thì chúng ta nên giảm chi phí gas của calldata giao dịch. Kích thước khối trung bình hiện tại không ở gần kích thước đe dọa đến sự ổn định của mạng Ethereum, do đó, có khả năng an toàn để làm như vậy, mặc dù có thể cần một số logic bổ sung để ngăn chặn các trường hợp cạnh rất không an toàn.nhìn thấyĐề xuất EIP-4488
EIP-4488：
https://github.com/ethereum/EIPs/pull/4488
EIP-4490：
https://github.com/ethereum/EIPs/pull/4490
, hoặc cách khác (đơn giản nhưng nhẹ nhàng hơn)Đề xuất EIP-4490.EIP 4488 sẽ có thể1 MBmỗi kheKhông gian dữ liệu có sẵn cho Tổng số được tăng lên mức tối đa theo lý thuyết là xấp xỉ.Chi phí thấp hơn khoảng 5 lần
. Điều này có thể đạt được nhanh hơn các bước sau.
tiêu đề cấp đầu tiênBước 2: Một số mảnhTrong thời gian chờ đợi, chúng tôi có thể bắt đầu thực hiện một số công việc để triển khai các phân đoạn "thích hợp". Sẽ mất nhiều thời gian để triển khai sharding ở dạng hoàn chỉnh (chức năng), nhưng những gì chúng ta có thể làm là triển khai từng bước và thu được lợi ích từ mỗi bước. Trước hết, việc triển khai "logic nghiệp vụ" của đặc tả sharding là điều tự nhiên, nhưng cần phảiLàm cho số lượng phân đoạn hoạt động đầu tiên rất thấp(ví dụ: 4 phân đoạn) để tránh hầu hết các khó khăn xung quanh mạng phân đoạn. Mỗi shard sẽ là của riêng mình
mạng con
phát tin. Theo mặc định, những người xác thực sẽ tin tưởng vào ủy ban, nhưng họ có thể chọn tham gia vào từng mạng con nếu muốn, nhưng họ sẽ chỉ nhận được điều đó nếu họ đã xem toàn bộ dữ liệu của bất kỳ khối phân đoạn nào được xác nhận bởi khối đèn hiệu.
Bản thân thông số kỹ thuật của shard không đặc biệt khó khăn; nó có các thay đổi mã soạn sẵn có kích thước tương tự như hard fork Altair được phát hành gần đây (tệp thông số kỹ thuật thay đổi đèn hiệu của altair là 728 dòng, tệp thông số kỹ thuật thay đổi đèn hiệu của shard là 888 dòng), do đó, điều hợp lý là kỳ vọng rằng nó có thể đạt được trong khung thời gian tương tự như quá trình triển khai và triển khai của Altair.
Để dữ liệu được phân đoạn thực sự có thể sử dụng được bởi Rollup, Rollup sẽ cần có khả năng lấy bằng chứng của chúng vào dữ liệu được phân đoạn. Có hai lựa chọn:
Thêm khả năng biên dịch trước quyền truy cập trạng thái và lịch sử trong tương lai để Rollup không cần thay đổi mã của chúng khi sơ đồ cam kết thay đổi trong tương lai.
Điều này sẽ tăng dung lượng dữ liệu Tổng số trên mỗi vị trí lên khoảng 2 MB (250 kB mỗi phân đoạn * 4 phân đoạn, cộng với calldata mở rộng ở Bước 1 ở trên).
tiêu đề cấp đầu tiên
Tăng số lượng mảnh hoạt động từ 4 lên 64. Tại thời điểm này, dữ liệu được chia nhỏ sẽ đi vào các mạng con, do đó, lớp P2P tại thời điểm đó phải đủ mạnh để có thể chia dữ liệu đó thành một số lượng lớn hơn các mạng con. Tính bảo mật của tính khả dụng của dữ liệu sẽ dựa trên giả định về tính trung thực của đa số (người xác thực), dựa trên tính bảo mật của ủy ban.
Điều này sẽ tăng dung lượng dữ liệu Tổng số trên mỗi vị trí lên khoảng 16 MB (250 kB mỗi phân đoạn * 64 phân đoạn); chúng tôi giả định rằng các Tổng số sẽ được di chuyển khỏi chuỗi thực thi Ethereum vào thời điểm này.
tiêu đề cấp đầu tiên
Lấy mẫu tính khả dụng của dữ liệu (DAS) được thêm vào để đảm bảo mức độ bảo mật cao hơn, cho phép người dùng được bảo vệ ngay cả trong trường hợp bị tấn công không trung thực bởi đa số (người xác thực). Việc lấy mẫu tính khả dụng của dữ liệu có thể được thực hiện theo các giai đoạn: đầu tiên, theo cách không ràng buộc để cho phép mạng kiểm tra dữ liệu đó, sau đó là yêu cầu để nhận các khối báo hiệu, thậm chí có thể trước tiên trên một số máy khách.
Sau khi lấy mẫu tính khả dụng của dữ liệu được giới thiệu đầy đủ, quá trình trải rộng các phân đoạn hoàn tất.
tiêu đề cấp đầu tiên
Tổng số lạc quan dựa trên mảnh và Tổng số ZK
Một trong những điểm khác biệt chính giữa Ethereum hiện tại và Ethereum sau khi triển khai sharding là trong thế giới của sharding, dữ liệu Rollup thực sự không thể là một phần của giao dịch gửi khối Rollup cho hợp đồng thông minh. Thay vào đó, việc xuất bản dữ liệu Tổng số và gửi các khối Tổng số sẽ phải tách biệt: đầu tiên, xuất bản dữ liệu sẽ đưa dữ liệu vào chuỗi (nghĩa là vào chuỗi phân đoạn), sau đó gửi khối sẽ gửi tiêu đề khối và Một bằng chứng trỏ đến dữ liệu cơ bản.ZK-SNARKOptimism và Arbitrum đã sử dụng thiết kế hai bước cho các lần xác nhận khối Rollup, vì vậy đây sẽ là một thay đổi mã nhỏ cho cả hai.
Với ZK Rollups, mọi thứ phức tạp hơn một chút, vì việc thực hiện giao dịch yêu cầu cung cấp bằng chứng rằng hoạt động trực tiếp thực hiện trên dữ liệu. họ có thể vượt quaĐể chứng minh rằng dữ liệu trong phân đoạn phù hợp với cam kết trên beacon chain, nhưng thao tác này rất tốn kém. May mắn thay, có những lựa chọn thay thế rẻ hơn.Nếu ZK-SNARK dựa trên BLS12-381
, thì họ có thể chỉ cần đóng gói trực tiếp cam kết dữ liệu phân đoạn làm đầu vào. Cam kết dữ liệu phân đoạn BLS12-381 là một cam kết KZG, cùng loại cam kết như trong PLONK, vì vậy nó có thể được chuyển trực tiếp vào bằng chứng dưới dạng đầu vào công khai.
Nếu ZK-SNARK sử dụng một số cơ chế khác (hoặc thậm chí là BLS12-381 PLONK nhưng với thiết lập đáng tin cậy hơn), thì ZK-SNARK có thể bao gồm cam kết dữ liệu của riêng mình và sử dụng bằng chứng tương đương để xác minh rằng cam kết trong bằng chứng là cam kết giống như vậy dữ liệu dưới dạng cam kết trong chuỗi đèn hiệu.
tiêu đề cấp đầu tiênTrong một thế giới bị chia cắt, ai sẽ lưu trữ dữ liệu lịch sử?Một điều kiện cần thiết để tăng không gian dữ liệu là
Xóa thuộc tính mà giao thức lõi Ethereum chịu trách nhiệm duy trì vĩnh viễn tất cả dữ liệu đạt được sự đồng thuận
. Vì lượng dữ liệu này quá lớn. Ví dụ:
Kích thước chuỗi tối đa theo lý thuyết do EIP-4488 mang lại là khoảng 1.262.861 byte trên mỗi khe 12 giây, tức là khoảng 3,0 TB mỗi năm, nhưng trên thực tế, có nhiều khả năng là khoảng 250-1000 GB mỗi năm, đặc biệt là vào thời gian đầu.
4 phân đoạn (1 MB mỗi khe) sẽ bổ sung thêm ~2,5 TB mỗi năm.
64 phân đoạn (16 MB mỗi khe) sẽ dẫn đến tổng dung lượng lưu trữ khoảng 40 TB mỗi năm.Hầu hết người dùng có ổ cứng từ 256 GB đến 2 TB, với 1 TB dường như là giá trị trung bình. Biểu đồ bên dưới là kết quả của một cuộc khảo sát nội bộ được thực hiện giữa một nhóm các nhà nghiên cứu blockchain về dung lượng ổ cứng máy tính:Điều này có nghĩa là người dùng hiện có thể chạy một nút, nhưng nếu bất kỳ phần nào của lộ trình này được triển khai mà không sửa đổi, thì người dùng sẽ không thể chạy nút. Tất nhiên, có sẵn các ổ đĩa lớn hơn, nhưng người dùng sẽ phải mất nhiều công sức để mua chúng, điều này làm tăng thêm đáng kể sự phức tạp khi chạy một nút. Giải pháp chính hiện tại là EIP-4444,
Đề xuất này loại bỏ trách nhiệm của các nhà khai thác nút trong việc lưu trữ các khối hoặc biên nhận cũ hơn 1 năm. Trong trường hợp phân đoạn, khoảng thời gian 1 năm này có thể sẽ được rút ngắn hơn nữa và các nút sẽ chỉ cần chịu trách nhiệm về các phân đoạn trên mạng con mà họ tích cực tham gia.
Điều này đặt ra một câu hỏi:Nếu giao thức lõi Ethereum không lưu trữ dữ liệu này thì ai sẽ làm?
Đầu tiên, điều quan trọng cần nhớ là ngay cả với sharding, lượng dữ liệu sẽ không lớn như vậy. Đúng vậy, 40 TB mỗi năm thực sự nằm ngoài tầm với của một cá nhân đang chạy phần cứng tiêu dùng "mặc định" (trên thực tế, thậm chí 1 TB mỗi năm vẫn là như vậy). Tuy nhiên, đối với một người sẵn sàng đầu tư một số tài nguyên và tìm cách lưu trữ dữ liệu này, điều này nằm trong phạm vi chấp nhận được. Một ổ cứng HDD (ổ đĩa cứng) 48 TB hiện được bán với giá 1.729 USD và 14 TB là khoảng 420 USD. Ai đó đang chạy vị trí trình xác thực 32 ETH có thể sẵn sàng thanh toán và lưu trữ toàn bộ chuỗi sau khi sharding được triển khai vì mục đích đặt phần thưởng. Do đó, trong thực tế, "không ai sẽ lưu trữ một số dữ liệu lịch sử của một phân đoạn nhất định để dữ liệu bị mất hoàn toàn"
Tình huống này dường như là không thể.
Vậy ai sẽ lưu trữ dữ liệu này? Một số suy nghĩ của tôi:
tình nguyện viên cá nhân và tổ chức;
Các trình khám phá khối (etherchain.org, etherscan.io, amberdata.io, v.v.) chắc chắn sẽ lưu trữ tất cả dữ liệu, vì mô hình kinh doanh của họ là cung cấp dữ liệu cho người dùng.
Rollup DAO chỉ định và trả tiền cho người tham gia để lưu trữ và cung cấp dữ liệu lịch sử liên quan đến Rollup của họ.
Dữ liệu lịch sử có thể được tải lên và chia sẻ qua torrent.
Khách hàng có thể tự nguyện chọn lưu trữ ngẫu nhiên 0,05% dữ liệu lịch sử của chuỗi khối (sử dụng mã xóa để chỉ một phần nhỏ dữ liệu bị mất nếu nhiều khách hàng ngoại tuyến cùng một lúc).
Khách hàng trong Mạng cổng thông tin có thể lưu trữ ngẫu nhiên một phần dữ liệu lịch sử của chuỗi khối và Mạng cổng thông tin sẽ tự động chuyển yêu cầu dữ liệu đến nút lưu trữ dữ liệu.
Việc lưu trữ dữ liệu lịch sử có thể được khuyến khích trong giao thức.
