Không có thông báo mới
Thêm
Màu sắc tăng giảm
Thời gian bắt đầu tăng giảm
- Chủ đề
122k Trạng thái
72k Trạng thái
67k Trạng thái
58k Trạng thái
56k Trạng thái
49k Trạng thái
45k Trạng thái
44k Trạng thái
44k Trạng thái
- 10#DOGE#
43k Trạng thái
- Ghim
- ⭐ Tham gia Gate.io Post, Khám phá xu hướng ngành và Chia sẻ những hiểu biết và chiến lược
💎 Trở thành Đại sứ Gate.io Post và tận hưởng những lợi ích độc quyền
⛏️ Kiếm lợi suất lên đến 10% với #Contentmining#
🎁 Tham gia vào các sự kiện hàng tuần và nhận phần thưởng
▶️ Tham gia ngay: https://www.Gate.io.io/post
#GatePost#
- 💰 Phần thưởng #USDE# cho ngày 03-15 đã được phân phối!
🤑 Hồ bơi phần thưởng 100 triệu đô la #USDE# vẫn mở - đừng bỏ lỡ!
Các bước để tham gia:
1️⃣ Click "Tham gia ngay": https://www.gate.io/campaigns/190-usde-100-m
2️⃣ Giữ ít nhất 10 $USDE trong tài khoản của bạn
3️⃣ Tận hưởng phần thưởng 29% APR, được cộng hàng ngày!
🗓 Sự kiện kết thúc vào ngày 23 tháng 12 lúc 00:00 (UTC)
Chi tiết: https://www.gate.io/announcements/article/41257
- 📢 Thách thức thẻ bài đăng Gate.io: #My Favorite Gate Post Feature# Đăng và NHẬN $100!
Bạn sử dụng tính năng nào nhiều nhất trên Gate.io? Bài viết? Đăng ký? Trò chuyện? Tín dụng danh dự? Hoặc Chủ đề gợi ý? Bạn muốn thấy những tính năng hay chức năng mới nào? Hãy chia sẻ kinh nghiệm và thông tin của bạn, và để nhiều người khám phá sự hấp dẫn của Gate.io!
💡Cách tham gia
1️⃣ Theo dõi gate_Post
2️⃣ Mở ứng dụng Gate.io, nhấp vào "Moments" ở dưới để vào trang "Post-Square".
3️⃣ Nhấp vào nút Đăng trong góc dưới bên phải, sử dụng hashtag #My Favorite Gate Post Feature# và đăng bài viết về quan điểm c
- 🎅 #ChristmasWonderland# Bữa Tiệc Làm Nóng
🥳 Tham gia để Mở khóa Cơ hội Trò chơi Sớm - $50,000 trong các Quà Giáng sinh đang chờ đợi!
✔️ Gửi UID & Nhận Vé Miễn Phí cùng bạn bè: https://www.gate.io/questionnaire/5732
⬇️ Hướng dẫn chơi Christmas Wonderland
#Christmas2024# - 🎉 Bài đăng của Gate.io đạt hơn 30.000 người theo dõi! 🎉
💰 Để kỷ niệm, chúng tôi đang tặng cho bạn $200 USD giá trị của các token! 💰
📝 Cách tham gia:
1. Theo dõi Gate.io_Post
2. Đăng bài với hashtag #GatePost30KFollowers# và chia sẻ những lời chúc tốt đẹp nhất cho Gate.io Post hoặc những đề xuất để cải thiện.
🗓 Deadline: December 19th, 12:00 PM (UTC)
🔔 20 Fan may mắn sẽ mỗi người nhận được $10 Đô la Tokens!
❤️ Cảm ơn bạn vì sự hỗ trợ tuyệt vời! Hãy cùng nhau đạt được những cột mốc tuyệt vời hơn nữa!
#GatePost30KFollowers# #GatePost#
Bài viết mới của Vitalik: Tương lai có thể của Ethereum, The Verge
原文标题：《Tương lai có thể của giao thức Ethereum, phần 4: The Verge》
原文作者：Vitalik Buterin
Original translation: Mensh, ChainCatcher
Đặc biệt cảm ơn Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams và Uma Roy về phản hồi và xem xét.
Một trong những tính năng mạnh mẽ nhất của Khối链 là bất kỳ ai cũng có thể chạy một Nút trên máy tính của mình và xác minh tính chính xác của Khối链. Ngay cả khi 9596 Nút chạyNhận thức chung chuỗi (PoW, PoS) đồng ý ngay lập tức thay đổi quy tắc và bắt đầu sản xuất Khối theo quy tắc mới, mọi người chạy Nút đã xác minh hoàn toàn sẽ từ chối chấp nhận chuỗi. Người đào coin không thuộc về nhóm âm mưu này sẽ tự động tụ hợp vào chuỗi on-chain tiếp tục tuân thủ theo quy tắc cũ và tiếp tục xây dựng chuỗi này, trong khi người dùng đã xác minh hoàn toàn sẽ tuân theo chuỗi này.
Điều này là sự khác biệt then chốt giữa blockchain và hệ thống tập trung. Tuy nhiên, để tính năng này trở thành sự thật, việc chạy một nút xác minh đầy đủ cần phải khả thi đối với đủ số người. Điều này áp dụng cả cho người tạo ra sự lan truyền (vì nếu họ không xác minh chuỗi, họ sẽ không đóng góp cho việc thực hiện các quy tắc giao thức), cũng như người dùng thông thường. Ngày nay, việc chạy nút trên máy tính xách tay tiêu dùng (bao gồm cả máy tính xách tay được sử dụng để viết bài này) là khả thi, nhưng việc làm điều này lại rất khó khăn. The Verge đang muốn thay đổi tình trạng này, làm cho chi phí tính toán của chuỗi xác minh đầy đủ trở nên rẻ hơn, để mỗi chiếc điện thoại Ví tiền, trình duyệt Ví tiền thậm chí cả đồng hồ thông minh đều mặc định thực hiện xác minh.
Bản đồ con đường The Verge 2023
Ban đầu, "Verge" chỉ đơn giản là việc chuyển trạng thái lưu trữ của ETH sang cây Verkle - một cấu trúc cây cho phép chứng minh nhỏ gọn hơn, giúp xác minh các khối ETH mà không cần lưu trữ bất kỳ trạng thái ETH nào (số dư tài khoản, mã hợp đồng, không gian lưu trữ...) trên đĩa cứng của nút. Chi phí là một vài trăm KB dữ liệu chứng minh và vài trăm mili giây thời gian bổ sung để xác minh một chứng minh. Hiện nay, Verge đại diện cho một tầm nhìn lớn hơn, tập trung vào việc thực hiện xác minh tài nguyên lớn nhất của chuỗi ETH, bao gồm không chỉ công nghệ xác minh không trạng thái mà còn bao gồm việc sử dụng SNARK để xác minh tất cả các thực thi ETH trên chuỗi.
Ngoài việc theo dõi dài hạn của toàn bộ chuỗi bằng phương pháp xác minh SNARK, một vấn đề mới khác liên quan đến việc xem xét xem cây Verkle có phải là công nghệ tốt nhất không. Cây Verkle dễ bị tấn công bởi Máy tính lượng tử, vì vậy nếu chúng ta thay thế cây Verkle trong cây Patricia Merkle KECCAK hiện tại, chúng ta sẽ phải thay thế cây một lần nữa trong tương lai. Phương pháp tự thay thế của cây Merkle là bỏ qua việc sử dụng nhánh Merkle và sử dụng STARK, đặt chúng vào một cây nhị phân. Lịch sử cho thấy, phương pháp này luôn được coi là không thể thực hiện do chi phí và độ phức tạp kỹ thuật. Tuy nhiên, gần đây, chúng ta đã thấy Starkware chứng minh 1,7 triệu giá trị Hàm băm Poseidon mỗi giây trên một máy tính xách tay bằng ckcle STARKs, và thời gian chứng minh giá trị Hàm băm "truyền thống" khác cũng đang được rút ngắn nhanh chóng do sự xuất hiện của các công nghệ như GKB. Do đó, trong năm qua, "Verge" đã trở nên mở rộng hơn và có nhiều khả năng hơn.
The Verge：Mục Tiêu Quan Trọng
Trong chương này
Xác minh không trạng thái: Verkle hay STARKs
Chúng tôi muốn giải quyết vấn đề gì?
Ngày nay, khách hàng ETH Fang cần lưu trữ hàng trăm gigabyte dữ liệu trạng thái để xác minh Khối, và con số này đang tăng lên hàng năm. Dữ liệu trạng thái thô tăng khoảng 30 GB mỗi năm và một khách hàng phải lưu trữ một số dữ liệu bổ sung trên đó để cập nhật bộ ba một cách hiệu quả.
Điều này giảm số lượng người dùng có thể chạy một Nút Ethereum đầy đủ xác thực: Mặc dù có đủ dung lượng để lưu trữ tất cả trạng thái Ethereum thậm chí là nhiều năm lịch sử trên ổ cứng lớn ở khắp mọi nơi, nhưng máy tính mà mọi người mua mặc định thường chỉ có vài trăm đến vài ngàn megabyte lưu trữ. Kích thước trạng thái cũng mang đến sự ma sát lớn cho quá trình xây dựng Nút lần đầu: Nút cần tải xuống toàn bộ trạng thái, điều này có thể mất vài giờ hoặc vài ngày. Điều này sẽ tạo ra nhiều tác động lan rộng. Ví dụ, nó tăng đáng kể độ khó của việc nâng cấp cài đặt Nút. Theo mặt kỹ thuật, có thể hoàn tất việc nâng cấp mà không cần tắt máy - khởi động một phiên bản khách hàng mới, đợi nó đồng bộ, sau đó tắt phiên bản khách hàng cũ và chuyển Chìa khoá bảo mật - nhưng trong thực tế, điều này rất phức tạp về mặt kỹ thuật.
Nó hoạt động như thế nào？
Xác minh không trạng thái là một công nghệ cho phép Nút xác minh Khối mà không cần kiểm soát toàn bộ trạng thái. Thay vào đó, mỗi Khối đi kèm với một bằng chứng, bao gồm: (i) giá trị, mã, số dư, lưu trữ tại vị trí cụ thể trong trạng thái mà Khối sẽ truy cập; (ii) chứng minh rằng các giá trị này là chính xác mã hóa.
Trong thực tế, việc thực hiện xác minh không trạng thái đòi hỏi thay đổi cấu trúc cây trạng thái của Ethereum. Điều này bởi vì cây Merkle Patricia hiện tại rất không thân thiện với bất kỳ hệ thống chứng minh mã hóa nào, đặc biệt là trong trường hợp xấu nhất. Cả 'cành' Merkle gốc và khả năng 'đóng gói' thành STARK đều vậy. Khó khăn chính đến từ một số điểm yếu của MPT:
Đây là một cây sáu nút (nghĩa là mỗi nút có 16 nút con). Điều này có nghĩa là trong một cây có kích thước N, một chứng minh trung bình cần 32*( 16-1)*log 16(N) = 120* log 2(N) byte, hoặc khoảng 3840 byte trong một cây có khoảng 2 ^ 32 mục. Đối với cây nhị phân, chỉ cần 32*( 2-1)*log 2(N) = 32* log 2(N) byte, hoặc khoảng 1024 byte.
Mã không được Merkle hóa. Điều này có nghĩa là để chứng minh bất kỳ quyền truy cập nào vào mã tài khoản, bạn cần cung cấp toàn bộ mã, tối đa là 24000 byte.
Chúng ta có thể tính toán trường hợp tồi nhất như sau:
30000000 gas / 2400 (tài khoản đọc lạnh thành chi phí) * (5 * 488 + 24000) = 330000000 byte
Chi phí của chi nhánh nhỏ hơn một chút (sử dụng 5 * 480 thay cho 8 * 480), vì khi có nhiều chi nhánh, phần đầu đỉnh sẽ xuất hiện nhiều lần. Nhưng ngay cả như vậy, việc tải xuống lượng dữ liệu trong một khung thời gian là hoàn toàn không thực tế. Nếu chúng ta cố gắng đóng gói nó bằng STARK, chúng ta sẽ gặp hai vấn đề: (i) KECCAK ít thân thiện với STARK; (ii) với 330 MB dữ liệu, chúng ta phải chứng minh 5 triệu cuộc gọi vòng lặp KECCAK, điều này có thể không chứng minh được cho tất cả các phần cứng ngoại trừ phần cứng tiêu dùng mạnh nhất, ngay cả khi chúng ta có thể làm cho STARK chứng minh hiệu quả hơn cho KECCAK.
Nếu chúng ta sử dụng cây nhị phân trực tiếp thay cho cây hệ thập lục phân và thực hiện xử lý Merkle bổ sung cho mã, trong trường hợp xấu nhất, tổng cộng sẽ là khoảng 30000000/2400 * 32 * (32-14+8) = 10400000 byte (14 là phép trừ dư của các bit tương đương với 2 ^ 14 nhánh và 8 là độ dài chứng minh vào các khối mã lá). Cần lưu ý rằng điều này đòi hỏi thay đổi chi phí gas, tính phí cho việc truy cập vào từng khối mã riêng lẻ; EIP-4762 đã thực hiện điều này. Dung lượng 10.4 MB tốt hơn nhiều, nhưng đối với nhiều nút, dữ liệu tải xuống trong một time slot vẫn quá nhiều. Do đó, chúng ta cần giới thiệu công nghệ mạnh mẽ hơn. Trong lĩnh vực này, có hai giải pháp tiên tiến: cây Verkle và cây băm nhị phân STARKed.
Cây Verkle
Cây Verkle sử dụng cam kết vector dựa trên đường cong elliptic để làm chứng ngắn hơn. Khóa mở cần phải biết rằng, bất kể chiều rộng của cây là bao nhiêu, mỗi phần chứng chỉ tương ứng với mỗi mối quan hệ cha con chỉ có 32 byte. Giới hạn duy nhất của chiều rộng cây chứng chỉ là nếu cây chứng chỉ quá rộng, hiệu suất tính toán chứng chỉ sẽ bị giảm. Đề xuất triển khai cho Ethereum có chiều rộng là 256.
Do đó, kích thước của một nhánh trong chứng minh trở thành 32 - 1 og 256(N) = 4* log 2(N) byte. Do đó, kích thước chứng minh tối đa lý thuyết là khoảng 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 byte (kết quả tính toán thực tế có thể khác nhau một chút do sự phân phối không đồng đều của khối trạng thái, nhưng là giá trị xấp xỉ đầu tiên).
Một điều cần lưu ý khác là trong tất cả các ví dụ trên, trường hợp "tệ nhất" này không phải là tệ nhất: tệ hơn nữa là kẻ tấn công chủ ý "đào" hai địa chỉ Địa chỉ, làm cho chúng có tiền tố chung dài hơn trong cây và đọc dữ liệu từ một trong hai Địa chỉ đó, điều này có thể kéo dài chiều dài của nhánh tệ nhất lên gấp đôi. Nhưng ngay cả khi có trường hợp như vậy, chiều dài chứng minh tệ nhất của cây Verkle vẫn là 2,6 MB, khá tương đồng với dữ liệu kiểm tra tệ nhất hiện tại.
Chúng tôi cũng đã sử dụng lưu ý này để làm một điều khác: chúng tôi đã làm cho chi phí truy cập không gian lưu trữ "liền kề" trở nên rất thấp: hoặc là nhiều khối mã của cùng một hợp đồng, hoặc là các khe lưu trữ liền kề. EIP - 4762 cung cấp định nghĩa về liền kề, chỉ thu phí 200 gas cho truy cập liền kề. Trong trường hợp truy cập liền kề, kích thước chứng minh trong trường hợp xấu nhất trở thành 30000000 / 200* 32 - 4800800 byte, điều này vẫn nằm trong khoảng sai số. Nếu vì an toàn mà chúng ta muốn giảm giá trị này, có thể tăng mức phí truy cập liền kề một chút.
Cây băm nhị phân STARKed
Nguyên lý công nghệ này rõ ràng không cần phải nói: bạn chỉ cần tạo một cây nhị phân, lấy chứng minh có kích thước tối đa 10.4 MB để chứng minh giá trị trong khối, sau đó thay thế chứng minh bằng STARK đã được chứng minh. Như vậy, chứng minh chính chỉ chứa dữ liệu được chứng minh và một chi phí cố định từ STARK thực tế là 100-300 kB.
Thách thức chính ở đây là thời gian xác minh. Chúng ta có thể thực hiện các tính toán cơ bản tương tự như trên, chỉ khác là chúng ta tính toán không phải là số byte mà là giá trị băm. Một Khối có kích thước 10,4 MB có nghĩa là 330,000 giá trị băm. Nếu kèm theo khả năng của kẻ tấn công "đào" các Địa chỉ cây có tiền tố công cộng dài, thì số lượng giá trị băm trong trường hợp tồi tệ nhất sẽ lên đến khoảng 660,000 giá trị băm. Do đó, nếu chúng ta có thể chứng minh rằng số lượng giá trị băm mỗi giây là 200,000, thì không vấn đề gì cả.
Trên các laptop tiêu dùng sử dụng hàm băm Poseidon, các con số này đã đạt đến, trong khi hàm băm Poseidon được thiết kế đặc biệt cho tính thân thiện với STARK. Tuy nhiên, hệ thống Poseidon vẫn còn chưa chín chắn, vì vậy nhiều người vẫn không tin tưởng vào tính an toàn của nó. Do đó, có hai con đường tiến lên thực tế:
Để chứng minh hàm băm bảo mật, vòng STARK của Starkware chỉ có thể chứng minh từ 10-30 k giá trị băm mỗi giây trên laptop tiêu dùng vào thời điểm viết bài này. Tuy nhiên, công nghệ STARK đang được cải thiện nhanh chóng. Ngay cả vào ngày nay, công nghệ dựa trên GKR cũng cho thấy khả năng tăng tốc độ này lên trong khoảng từ 100-200 k.
Trường hợp sử dụng chứng thực ngoại trừ khối
Ngoài việc xác minh Khối, còn có ba trường hợp sử dụng quan trọng khác đòi hỏi xác minh không trạng thái hiệu quả hơn:
Tất cả các trường hợp sử dụng này đều có một điểm chung, đó là chúng cần rất nhiều chứng minh nhưng mỗi chứng minh lại rất nhỏ. Do đó, chứng minh STARK không có ý nghĩa thực tế đối với chúng; ngược lại, phương pháp hiện thực nhất là sử dụng trực tiếp các nhánh Merkle. Một ưu điểm khác của nhánh Merkle là tính cập nhật: với một chứng minh của đối tượng trạng thái X có gốc là Khối B, nếu nhận được một Khối con B 2 và chứng thực của nó, có thể cập nhật chứng minh để có gốc là Khối B 2. Chứng minh Verkle cũng có thể cập nhật một cách tự nhiên.
Có liên quan gì với nghiên cứu hiện có:
Còn có thể làm gì nữa?
Công việc chính còn lại là
Thêm phân tích về hậu quả của EIP-4762 (thay đổi chi phí gas không trạng thái)
Hoàn thành và thử nghiệm thêm công việc chuyển tiếp, đây là phần quan trọng của sự phức tạp của bất kỳ kế hoạch triển khai không quốc tịch nào
Phân tích bảo mật sâu hơn về các hàm băm Poseidon, Ajtai và các hàm băm "STARK-friendly" khác
4.为 "保守"（或 "传统"）Hàm băm进一步开发超高效 STARK giao thức功能，例如基于 Binius 或 GKR 的观点。
Ngoài ra, chúng tôi sẽ sớm quyết định chọn một trong ba lựa chọn sau: (i) cây Verkle, (ii) hàm băm thân thiện STARK và (iii) hàm băm bảo thủ. Các tính chất của chúng có thể được tóm tắt đại khái trong bảng dưới đây:
Ngoài các "số tiêu đề" này, còn có một số yếu tố quan trọng khác cần được xem xét:
Nếu chúng ta muốn có tính bảo mật về mặt lượng tử và hiệu quả hợp lý khi có tính khả năng cập nhật chứng cứ Verkle, một phương pháp khả thi khác là dựa trên cây Merkle dựa trên lưới lattice.
Nếu trong trường hợp xấu nhất, chứng minh hiệu suất của hệ thống không đủ cao, chúng ta có thể sử dụng công cụ gas đa chiều không mong đợi này để bù đắp điều đó: (i) calldata; (ii) tính toán; (iii) truy cập trạng thái và có thể là các tài nguyên khác có đặt giới hạn gas riêng biệt. Gas đa chiều tăng thêm sự phức tạp, nhưng như một trao đổi, nó hạn chế nghiêm ngặt tỷ lệ giữa trường hợp trung bình và trường hợp xấu nhất. Với gas đa chiều, lý thuyết về số nhánh tối đa cần chứng minh có thể giảm từ 12500 xuống ví dụ như 3000. Điều này sẽ giúp BLAKE 3 có đủ sức mạnh ngay cả trong ngày hôm nay (dù chỉ vừa đủ).
Gas đa chiều cho phép giới hạn tài nguyên của Khối gần hơn với giới hạn tài nguyên của phần cứng cấu trúc ở mức thấp
Một công cụ ngoài dự tính khác là tính toán trạng thái gốc Trễ đến khoảng thời gian sau Khối. Điều này có nghĩa là chúng ta có tới 12 giây để tính toán trạng thái gốc, điều này có nghĩa là ngay cả trong trường hợp cực đoan nhất, thời gian chứng minh mỗi giây cũng chỉ cần 60000 lần băm là đủ, điều này một lần nữa khiến chúng tôi nghĩ rằng BLAKE 3 chỉ đủ sức mạnh.
Phương pháp này có điểm yếu là sẽ tăng thêm một độ trễ khách hàng ánh sáng, nhưng cũng có các kỹ thuật tinh vi hơn có thể giảm độ trễ này xuống chỉ còn là Trễ sinh trắc nghiệm. Ví dụ, chứng minh có thể được phát sóng trên mạng ngay sau khi được sinh ra trên bất kỳ Nút nào, thay vì phải chờ đợi cho Khối tiếp theo.
Nó tương tác như thế nào với các phần khác của sơ đồ tuyến đường?
Giải quyết vấn đề không trạng thái đã làm tăng đáng kể độ khó của việc định vị đơn lẻ. Nếu có công nghệ có thể Thả cân bằng tối thiểu của việc định vị đơn lẻ, như Orbit SSF hoặc chiến lược Lớp ứng dụng, như định vị nhóm, điều này sẽ trở nên khả thi hơn.
Nếu đồng thời giới thiệu EOF, phân tích gas đa chiều sẽ trở nên dễ dàng hơn. Điều này bởi vì nguồn gốc phức tạp chính của gas đa chiều đến từ việc xử lý các cuộc gọi con không truyền toàn bộ gas của cuộc gọi cha, trong khi EOF chỉ cần đặt các cuộc gọi con như vô hiệu, vấn đề này sẽ trở nên không đáng kể (và cung cấp một phương án thay thế nội bộ cho việc sử dụng gas hiện tại của tài khoản cục bộ một phần giao thức).
Giữa việc xác minh trạng thái và việc lịch sử hết hạn còn có một tương tác quan trọng. Hiện nay, máy khách phải lưu trữ gần 1 TB dữ liệu lịch sử; dữ liệu này là nhiều lần dữ liệu trạng thái. Ngay cả khi máy khách không có trạng thái, nếu chúng ta không thể giải phóng trách nhiệm lưu trữ dữ liệu lịch sử của máy khách, thì gần như là không thể thực hiện được ước mơ về việc không lưu trữ của máy khách. Bước đầu tiên trong việc này là EIP-4444, điều này cũng có nghĩa là lưu trữ dữ liệu lịch sử trong torrents hoặc Portal Network.
Bằng chứng hợp lệ được thực hiện bởi EVM
Chúng tôi muốn giải quyết vấn đề gì?
Mục tiêu lâu dài của việc xác minh Khối ETH là rõ ràng - có thể xác minh Khối ETH theo cách sau đây: (i) Tải xuống Khối hoặc thậm chí chỉ tải xuống một phần nhỏ của dữ liệu sẵn có trong Khối; (ii) Xác minh một chứng chỉ nhỏ về tính hợp lệ của Khối. Đây sẽ là một hoạt động tài nguyên rất thấp, có thể được thực hiện trên điện thoại di động, ví tiền trình duyệt hoặc thậm chí trên một chuỗi khác (không có phần dữ liệu sẵn có).
Để đạt được điều này, cần phải chứng minh SNARK hoặc STARK cho (i) lớp đồng thuận (Proof of Stake) và (ii) lớp thực thi (EVM). Đối với phần đầu tiên, đó là một thách thức riêng biệt và cần được giải quyết trong quá trình cải tiến liên tục lớp đồng thuận (ví dụ: đối với quyết định cuối cùng của một khe đơn). Còn với phần sau, cần chứng minh thực thi EVM.
Nó là gì, làm thế nào hoạt động?
Từ mặt hình thức, trong đặc tả của Ethereum (ETH), EVM được xác định là một hàm chuyển trạng thái: bạn có một trạng thái trước S, một Khối B và bạn đang tính toán một trạng thái sau S' = STF(S, B). Nếu người dùng sử dụng khách hàng ánh sáng, họ không hoàn toàn sở hữu S và S', thậm chí không có E; thay vào đó, họ sở hữu một gốc trạng thái trước R, một gốc trạng thái sau R' và một giá trị băm của Khối H.
Nếu có tình huống như vậy, bạn có thể sở hữu một phiên bản khách hàng nhẹ hoàn toàn xác minh việc thực thi EVM của Ethereum. Điều này khiến tài nguyên của khách hàng đã rất thấp. Để thực hiện một phiên bản khách hàng Ethereum hoàn toàn xác minh thực sự, bạn cũng cần làm việc tương tự với Nhận thức chung.
Hiện tại đã có sự triển khai của bằng chứng hợp lệ để sử dụng trong việc tính toán EVM và nó đã được sử dụng rộng rãi trên L2. Tuy nhiên, để làm cho bằng chứng hợp lệ EVM trên L1 trở nên khả thi, cần phải thực hiện nhiều công việc.
Có mối liên hệ nào với các nghiên cứu hiện có không?
Còn có thể làm gì nữa?
Hiện nay, hệ thống ghi chú điện tử đang tồn tại hai vấn đề chưa đủ: an ninh và thời gian xác minh.
Một bằng chứng hợp lệ an toàn cần đảm bảo rằng SNARK thực sự xác minh tính toán của EVM và không có lỗ hổng. Hai công nghệ chính để nâng cao tính bảo mật là đa xác minh và xác minh hình thức. Đa xác minh đề cập đến việc có nhiều bằng chứng hợp lệ độc lập được triển khai, tương tự như có nhiều khách hàng, nếu một khối được chứng minh bởi một tập con đủ lớn trong các triển khai này, khách hàng sẽ chấp nhận khối đó. Xác minh hình thức liên quan đến việc sử dụng các công cụ thường được sử dụng để chứng minh các định lý toán học, như Lean 4, để chứng minh rằng bằng chứng hợp lệ chỉ chấp nhận việc thực hiện chính xác các quy tắc EVM cơ bản (ví dụ như ngữ nghĩa EVM K hoặc quy tắc thi hành tầng EELS được viết bằng Python).
Thời gian xác minh đủ nhanh có nghĩa là bất kỳ khối ETH nào cũng có thể được xác minh trong thời gian ít hơn 4 giây. Hiện nay, chúng ta còn rất xa mới đạt được mục tiêu này, mặc dù chúng ta đã tiến gần hơn nhiều so với hai năm trước. Để đạt được mục tiêu này, chúng ta cần tiến bộ theo ba hướng:
Có những thách thức để đạt được điều này. Ngay cả trong trường hợp xấu nhất, khi một giao dịch rất lớn chiếm toàn bộ Khối, việc phân vùng tính toán không thể được thực hiện trên cơ sở mỗi lần, mà phải được thực hiện trên cơ sở mỗi opcode (opcode của Máy ảo cơ bản như EVM hoặc RISC-V). Đảm bảo rằng "bộ nhớ" của Máy ảo nhất quán trên các phần khác nhau của bằng chứng là một thách thức chính trong quá trình thực hiện. Tuy nhiên, nếu chúng ta có thể thực hiện loại chứng minh đệ quy này, thì chúng ta biết rằng ngay cả khi không có cải tiến nào khác, ít nhất vấn đề Trễ của người chứng minh đã được giải quyết.
Thay đổi chi phí gas - Nếu một hoạt động mất nhiều thời gian để chứng minh, thì dù tốc độ tính toán của nó nhanh hơn, cũng nên có chi phí gas cao. EIP-7667 là một EIP được đưa ra để giải quyết vấn đề nghiêm trọng nhất trong việc này: nó tăng đáng kể chi phí gas của các hàm băm (truyền thống) vì các opcode và precompile của chúng rẻ relativ. Để bù đắp cho sự tăng chi phí gas này, chúng ta có thể giảm chi phí gas của các opcode EVM có chứng minh tương đối thấp, từ đó duy trì số lượng giao dịch trung bình không thay đổi.
Thay đổi cấu trúc dữ liệu - Ngoài việc thay thế cây trạng thái bằng cách thân thiện với STARK, chúng ta cũng cần thay thế danh sách giao dịch, cây biên nhận và các cấu trúc khác tốn kém chi phí chứng minh. Việc Etan Kissling chuyển cấu trúc giao dịch và biên nhận sang SSZ trong EIP là một bước tiến trong hướng đó.
Ngoài ra, hai công cụ đã được đề cập trong phần trước (gas đa chiều và gốc trạng thái Trễ) cũng có thể cung cấp hỗ trợ trong lĩnh vực này. Tuy nhiên, điều đáng lưu ý là, khác với xác thực không trạng thái, việc sử dụng hai công cụ này đồng nghĩa với việc chúng ta đã có đủ kỹ thuật để hoàn thành công việc hiện tại của chúng ta, và ngay cả khi sử dụng các kỹ thuật này, xác thực ZK-EVM đầy đủ cũng cần nhiều hơn nữa công việc - chỉ cần ít hơn thôi.
Một điểm không được đề cập trong bài viết là phần cứng chứng minh: sử dụng GPU, FPGA và ASIC để tạo ra chứng minh nhanh hơn. Fabric Cryptography, Cysic và Accseal là ba công ty đã tiến bộ trong lĩnh vực này. Điều này rất có giá trị đối với L2, nhưng không có khả năng trở thành yếu tố quyết định cho L1, vì mọi người mong muốn L1 duy trì tính phi tập trung cao, điều này có nghĩa là việc tạo ra chứng minh phải nằm trong phạm vi hợp lý của người dùng ETH, không bị hạn chế bởi phần cứng của một công ty duy nhất. L2 có thể đưa ra sự cân nhắc tích cực hơn.
Trong những lĩnh vực này, còn nhiều công việc phải làm:
Chi phí có thể là:
Làm thế nào nó tương tác với các phần khác của bản đồ đường đi?
Công nghệ cốt lõi cần thiết để thực hiện L1 EVM bằng chứng hợp lệ chia sẻ rất nhiều với hai lĩnh vực khác:
Đạt được bằng chứng hợp lệ trên L1 sẽ cuối cùng dẫn đến việc thế chấp đơn giản: ngay cả máy tính yếu nhất (bao gồm điện thoại di động hoặc đồng hồ thông minh) cũng có thể thế chấp. Điều này làm tăng thêm giá trị của việc giải quyết các ràng buộc khác của việc thế chấp đơn giản (như mức tối thiểu là 32 ETH).
Ngoài ra, bằng chứng hợp lệ EVM của L1 có thể nâng cao đáng kể giới hạn gas của L1.
Bằng chứng hợp lệ của Nhận thức chung
Chúng tôi muốn giải quyết vấn đề gì?
Nếu chúng ta muốn hoàn toàn xác minh một khối ETH trong nhóm bằng SNARK, thì việc thực thi EVM không phải là phần duy nhất mà chúng ta cần phải chứng minh. Chúng ta cũng cần phải chứng minh Nhận thức chung, tức là một phần khác về việc xử lý gửi tiền, rút tiền, ký, cập nhật số dư của người xác minh và một số phần khác của Bằng chứng về cổ phần trong nhóm ETH.
Nhận thức chung比 EVM đơn giản hơn nhiều, nhưng thách thức mà nó đối mặt là chúng ta không có EVM L2 convolution, do đó phải hoàn thành phần lớn công việc dù sao. Do đó, bất kỳ việc thực hiện Nhận thức chung ETH坊 nào cũng cần phải "bắt đầu từ đầu", mặc dù hệ thống chứng minh chính nó có thể được xây dựng dựa trên công việc chia sẻ của nó.
Nó là gì, làm thế nào hoạt động?
beacon chain được định nghĩa là một hàm chuyển trạng thái, tương tự như EVM. Hàm chuyển trạng thái chủ yếu bao gồm ba phần:
Trong mỗi Khối, chúng ta cần chứng minh 1-16 BLS 12-381 ECADD cho mỗi trình xác thực (có thể có nhiều hơn một, vì chữ ký có thể được chứa trong nhiều bộ sưu tập). Điều này có thể được bù đắp bằng các kỹ thuật tính toán trước tập hợp con, vì vậy chúng ta có thể nói rằng mỗi Người xác thực chỉ cần chứng minh một ECADD BLS 12-381. Hiện tại, có 30.000 chữ ký xác thực cho mỗi vị trí. Trong tương lai, điều này có thể thay đổi theo hai hướng khi đạt được tính cuối cùng của một vị trí: nếu chúng ta đi theo con đường "vũ phu", số lượng Người xác thực trên mỗi vị trí có thể tăng lên 1 triệu. Đồng thời, nếu Orbit SSF được thông qua, số lượng trình xác nhận sẽ vẫn ở mức 32.768 hoặc thậm chí giảm xuống còn 8.192.
Cách hoạt động của BLS Aggregation: Chỉ cần một ECADD của mỗi người tham gia để xác minh chữ ký tổng cộng, thay vì một ECMUL. Tuy nhiên, 30000 ECADD vẫn là một lượng chứng cứ lớn.
Đối với việc ghép cặp, hiện tại mỗi khe chỉ có tối đa 128 chứng chỉ, điều này có nghĩa là cần xác minh 128 cặp. Thông qua ElP-7549 và các sửa đổi tiếp theo, mỗi khe có thể giảm xuống còn 16. Số lượng cặp ghép rất ít, nhưng chi phí rất cao: thời gian chạy (hoặc chứng minh) của mỗi cặp ghép dài gấp k lần so với ECADD.
Một thách thức chính của việc tính toán BLS 12-381 là không có đường cong với bậc bằng kích thước trường BLS 12-381, điều này tạo ra chi phí khá lớn cho bất kỳ hệ thống chứng minh nào. Ngược lại, cây Verkle được đề xuất cho ETH là được xây dựng trên đường cong Bandersnatch, điều này làm cho BLS 12-381 trở thành đường cong tự thể hiện trong hệ thống SNARK để chứng minh các nhánh Verkle. Một việc triển khai đơn giản có thể chứng minh được 100 G 1 phép cộng mỗi giây; để tăng tốc độ chứng minh đủ nhanh, hầu như chắc chắn cần các công nghệ tinh vi như GKR.
Đối với giá trị băm SHA 256, tình huống tồi tệ nhất hiện tại là khối chuyển đổi thời đại, toàn bộ cây cân bằng ngắn của người xác thực và nhiều cây cân bằng ngắn của người xác thực sẽ được cập nhật. Mỗi cây cân bằng ngắn của người xác thực chỉ có một byte, do đó có 1 MB dữ liệu sẽ được băm lại. Điều này tương đương với 32768 lần gọi SHA 256. Nếu có một nghìn người xác thực có số dư cao hơn hoặc thấp hơn một ngưỡng nhất định, cần cập nhật số dư hợp lệ trong bản ghi của người xác thực, điều này tương đương với một nghìn nhánh Merkle, do đó có thể cần 10000 lần giá trị băm. Cơ chế xáo trộn yêu cầu 90 Bit cho mỗi người xác thực (do đó cần 11 MB dữ liệu), nhưng điều này có thể tính toán bất kỳ lúc nào trong một thời đại. Trong trường hợp kết thúc một khe đơn, các con số này có thể tăng hoặc giảm tùy thuộc vào tình huống cụ thể. Việc xáo trộn trở nên không cần thiết, mặc dù Orbit có thể phục hồi một phần nhu cầu này.
Một thách thức khác là cần phải lấy lại tất cả trạng thái của tất cả các nhà xác thực, bao gồm cả Khóa công khai, mới có thể xác minh một Khối. Đối với 1 triệu nhà xác thực, việc chỉ đọc Khóa công khai cũng cần 48 triệu byte, cộng với các nhánh Merkle. Điều này đòi hỏi hàng triệu giá trị băm cho mỗi kỷ nguyên. Nếu chúng ta phải chứng minh tính hiệu quả của PoS, một phương pháp thực tế là một dạng tính toán có thể xác minh tăng dần nào đó: lưu trữ một cấu trúc dữ liệu độc lập bên trong hệ thống chứng minh, cấu trúc dữ liệu này được tối ưu hóa để tìm kiếm hiệu quả và chứng minh sự cập nhật đối với cấu trúc này.
Tóm lại, có rất nhiều thách thức. Để đối phó hiệu quả nhất với những thách thức này, có khả năng sẽ cần phải thiết kế lại beacon chain một cách sâu sắc, có thể đồng thời đi kèm với việc chuyển sang kết thúc một khe đơn. Những đặc điểm của việc thiết kế lại này có thể bao gồm:
Có mối liên hệ nào với các nghiên cứu hiện có không?
Còn công việc nào cần phải làm, làm thế nào để lựa chọn:
Thực tế, chúng tôi cần mất vài năm để có được bằng chứng hợp lệ về Nhận thức chung của Ethereum. Điều này tương đương với thời gian cần thiết để thực hiện Single-slot Finality, Orbit, thay đổi thuật toán chữ ký và phân tích bảo mật, trong đó phân tích bảo mật yêu cầu đủ sự tự tin để sử dụng các hàm băm "cực đoan" như Poseidon. Do đó, cách thông minh nhất là giải quyết các vấn đề khác này và cân nhắc tính thân thiện của STARK trong quá trình giải quyết các vấn đề này.
Cân nhắc chính có thể nằm ở thứ tự thực hiện, giữa một phương pháp tiến bộ hơn và một phương pháp "thay đổi một lần nhiều" táo bạo hơn trong việc cải cách lớp đồng thuận Ethereum. Phương pháp tiến bộ là hợp lý cho EVM vì nó giảm thiểu tác động đến tính tương thích ngược. Đối với lớp đồng thuận, tác động đến tính tương thích ngược nhỏ, và việc xem xét lại các chi tiết xây dựng beacon chain một cách "toàn diện" để tối ưu hóa tính thân thiện với SNARK cũng có lợi.
Nó tương tác như thế nào với các phần khác của sơ đồ tuyến đường?
Trong quá trình thiết kế lại dài hạn cho ETH Ethereum PoS, sự thân thiện của STARK phải trở thành yếu tố hàng đầu, đặc biệt là tính kết thúc của một khe hở, Orbit, thay đổi chữ ký và việc tổng hợp chữ ký.