Con đường đến tính xác thực

Ưu điểm cốt lõi của Web3 là tính xác minh - người dùng có thể xác minh cách hệ thống hoạt động thực sự. Điều này giải thích tại sao nhiều người trong và ngoài ngành công nghiệp tiền điện tử mô tả web3 như một bước tiến về một internet minh bạch và có thể xác minh hơn.

Khác với các nền tảng Web2 như Facebook hoặc Instagram, nơi các thuật toán và quy tắc vẫn không rõ ràng ngay cả khi đã được ghi chép, các giao thức crypto được thiết kế để hoàn toàn có thể kiểm tra. Ngay cả khi chúng được chia sẻ, bạn thiếu khả năng xác minh xem nền tảng hoạt động như đã được chỉ định hay không. Điều này hoàn toàn trái ngược với crypto, nơi mỗi giao thức được thiết kế để có thể được kiểm tra càng nhiều càng tốt - hoặc ít nhất là được kỳ vọng.

Hôm nay, chúng ta sẽ khám phá một phần từ bài viết gần đây của Vitalik về “The Verge”.chương trình gồm sáu phần về tương lai của Ethereum, để phân tích các bước mà Ethereum đang thực hiện để đạt được tính xác thực, bền vững và khả năng mở rộng trong tương lai. Dưới tiêu đề ‘The Verge’, chúng tôi sẽ thảo luận về cách kiến trúc blockchain có thể trở nên xác thực hơn, các đổi mới mà những thay đổi này mang lại ở mức giao thức và cách chúng cung cấp cho người dùng một hệ sinh thái an toàn hơn. Hãy bắt đầu!

“Khả năng kiểm chứng” có nghĩa là gì?

Các ứng dụng Web2 hoạt động như các “hộp đen” - người dùng chỉ có thể thấy các đầu vào của họ và các đầu ra tương ứng, mà không thể nhìn thấy cách thức hoạt động thực tế của ứng dụng. Ngược lại, các giao thức tiền điện tử thường làm cho mã nguồn của họ trở nên công khai, hoặc ít nhất có kế hoạch làm như vậy. Sự minh bạch này phục vụ hai mục đích: nó cho phép người dùng tương tác trực tiếp với mã nguồn của giao thức nếu họ muốn, và giúp họ hiểu rõ cách hệ thống hoạt động và những quy tắc quản lý nó.

“Phân tán những gì bạn có thể, xác minh phần còn lại.”

Xác thực đảm bảo hệ thống có tính chất có trách nhiệm và, trong nhiều trường hợp, đảm bảo rằng các giao thức hoạt động như dự định. Nguyên tắc này nhấn mạnh tầm quan trọng của việc giảm thiểu trung tâm hóa, vì nó thường dẫn đến các cấu trúc không minh bạch, không có trách nhiệm mà người dùng không thể xác minh hoạt động. Thay vào đó, chúng ta nên cố gắng phân tán càng nhiều càng tốt và tạo ra những yếu tố còn lại có thể xác thực và có trách nhiệm trong những trường hợp không thể phân tán.

Cộng đồng Ethereum dường như đồng ý với quan điểm này, khi lộ trìnhbao gồm một mốc (gọi là “The Verge”) nhằm mục tiêu làm cho Ethereum có thể xác minh hơn. Tuy nhiên, trước khi đi sâu vào The Verge, chúng ta cần hiểu rõ những khía cạnh của các chuỗi khối cần được xác minh và những phần quan trọng từ quan điểm của người dùng.

Blockchains về cơ bản hoạt động như các đồng hồ toàn cầu. Trong một mạng phân tán với khoảng 10.000 máy tính, một giao dịch có thể mất một thời gian đáng kể để lan truyền từ nút gốc đến tất cả các nút khác. Vì lí do này, các nút trên mạng không thể xác định chính xác thứ tự của các giao dịch - liệu một giao dịch đã đến trước hay sau một giao dịch khác - vì họ chỉ có quan điểm chủ quan của riêng mình.

Do vì thứ tự của giao dịch rất quan trọng, mạng blockchain sử dụng các phương pháp chuyên biệt được gọi là “các thuật toán đồng thuậnđể đảm bảo rằng các nút vẫn đồng bộ và xử lý chuỗi giao dịch theo cùng một thứ tự. Mặc dù các nút không thể xác định thứ tự giao dịch toàn cầu, cơ chế đồng thuận cho phép tất cả các nút đồng ý với cùng một chuỗi, cho phép mạng hoạt động như một máy tính đơn nhất.

Bên cạnh lớp đồng thuận, còn có lớp thực thi tồn tại trong mọi blockchain. Lớp thực thi được tạo ra bởi các giao dịch mà người dùng muốn thực hiện.

Sau khi giao dịch được xác nhận thành công bằng sự đồng thuận, mỗi giao dịch phải được áp dụng vào trạng thái hiện tại tại lớp thực thi. Nếu bạn đang tự hỏi, “Trạng thái là gì?”, có lẽ bạn đã thấy blockchain được so sánh với cơ sở dữ liệu—hoặc cụ thể hơn là cơ sở dữ liệu của ngân hàng vì blockchain, giống như ngân hàng, duy trì một bản ghi về số dư của mọi người.

Nếu bạn có $100 trong trạng thái chúng ta gọi là “S” và muốn gửi $10 cho người khác, số dư của bạn trong trạng thái tiếp theo, “S+1”, sẽ là $90. Quá trình áp dụng giao dịch để chuyển từ trạng thái này sang trạng thái khác chính là điều chúng ta gọi là chức năng chuyển trạng thái (STF).

Trong Bitcoin, STF chủ yếu giới hạn ở những thay đổi số dư, làm cho nó tương đối đơn giản. Tuy nhiên, khác với Bitcoin, STF của Ethereum phức tạp hơn nhiều vì Ethereum là một blockchain có thể lập trình hoàn toàn với một lớp thực thi có khả năng chạy mã.

Trong một chuỗi khối, có ba thành phần cơ bản mà bạn cần hoặc có thể xác minh:

1. Trạng thái: Bạn có thể muốn đọc một mảnh dữ liệu trên blockchain, nhưng thiếu quyền truy cập vào trạng thái vì bạn không chạy một full node. Vì vậy, bạn yêu cầu dữ liệu qua một nhà cung cấp RPC (Remote Procedure Call) như Alchemy hoặc Infura. Tuy nhiên, bạn phải xác minh rằng dữ liệu chưa bị thay đổi bởi nhà cung cấp RPC.
2. Thực thi: Như đã đề cập trước đó, các blockchain sử dụng một STF. Bạn phải xác minh rằng quá trình chuyển trạng thái đã được thực hiện đúng— không theo từng giao dịch mà theo từng khối.
3. Consensus: Các đơn vị bên thứ ba, như RPC, có thể cung cấp cho bạn các khối hợp lệ mà chưa được bao gồm trong blockchain. Do đó, bạn phải xác minh rằng những khối này đã được chấp nhận thông qua sự đồng thuận và được thêm vào blockchain.

Nếu điều này dường như rắc rối hoặc không rõ ràng, đừng lo lắng. Chúng tôi sẽ đi qua từng khía cạnh này một cách chi tiết. Hãy bắt đầu với cách xác minh trạng thái blockchain!

Làm thế nào để xác minh trạng thái blockchain?

“Trạng thái” của Ethereum đề cập đến tập hợp dữ liệu được lưu trữ trong blockchain tại bất kỳ thời điểm nào. Điều này bao gồm số dư tài khoản (tài khoản hợp đồng và tài khoản thuộc sở hữu bên ngoài hoặc EOA), mã hợp đồng thông minh, lưu trữ hợp đồng và hơn thế nữa. Ethereum là một máy dựa trên trạng thái vì các giao dịch được xử lý trong Máy ảo Ethereum (EVM) làm thay đổi trạng thái trước đó và tạo ra một trạng thái mới.

Mỗi khối Ethereum chứa một giá trị tóm tắt trạng thái hiện tại của mạng sau khối đó: stateRoot. Giá trị này là một biểu diễn nhỏ gọn của toàn bộ trạng thái Ethereum, bao gồm một băm 64 ký tự.

Khi mỗi giao dịch mới thay đổi trạng thái, trạng thái Gốc được ghi lại trong khối tiếp theo sẽ được cập nhật tương ứng. Để tính giá trị này, các người xác minh Ethereum sử dụng sự kết hợp của hàm băm Keccak và một cấu trúc dữ liệu gọi là Cây Merkletổ chức và tóm tắt các phần khác nhau của trạng thái.

Hàm băm là các hàm một chiều biến đổi một đầu vào thành một đầu ra cố định. Trong Ethereum, các hàm băm như Keccakđược sử dụng để tạo ra các bản tóm tắt dữ liệu, phục vụ như một loại vân tay cho đầu vào. Hàm băm có bốn tính chất cơ bản:

1. Determinism: Cùng một đầu vào sẽ luôn tạo ra cùng một đầu ra.
2. Độ dài đầu ra cố định: Bất kể độ dài đầu vào, độ dài đầu ra luôn cố định.
3. Tài sản một chiều: Thực tế là không thể tìm ra đầu vào gốc từ đầu ra.
4. Độc nhất vô nhị: Ngay cả một sự thay đổi nhỏ trong đầu vào tạo ra một đầu ra hoàn toàn khác nhau. Do đó, một đầu vào cụ thể tương ứng với một đầu ra gần như duy nhất.

Nhờ những tính chất này, các máy chủ xác nhận Ethereum có thể thực hiện chức năng chuyển đổi trạng thái (STF) cho mỗi khối - thực hiện tất cả giao dịch trong khối và áp dụng chúng vào trạng thái - sau đó xác minh xem trạng thái được chỉ ra trong khối có khớp với trạng thái thu được sau STF. Quá trình này đảm bảo người đề xuất khối đã hành động trung thực, làm cho đó trở thành một trong những trách nhiệm chính của các máy chủ xác nhận.

Tuy nhiên, người xác thực Ethereum không băm toàn bộ trạng thái trực tiếp để tìm tóm tắt của nó. Do tính chất một chiều của các hàm băm, việc băm trạng thái trực tiếp sẽ loại bỏ tính xác minh, vì cách duy nhất để tái tạo lại hàm băm sẽ là sở hữu toàn bộ trạng thái.

Vì trạng thái của Ethereum có kích thước hàng terabyte, nên không thực tế để lưu toàn bộ trạng thái trên các thiết bị hàng ngày như điện thoại hoặc máy tính cá nhân. Vì lý do này, Ethereum sử dụng cấu trúc cây Merkle để tính toán stateRoot, bảo tồn tính xác thực của trạng thái càng nhiều càng tốt.

Một cây Merklelà một cấu trúc dữ liệu mật mã được sử dụng để xác minh tính toàn vẹn và đúng đắn của dữ liệu một cách an toàn và hiệu quả. Cây Merkle được xây dựng dựa trên các hàm băm và tổ chức các giá trị băm của một tập dữ liệu theo cấp bậc, cho phép xác minh tính toàn vẹn và đúng đắn của dữ liệu này. Cấu trúc cây này bao gồm ba loại nút:

1. Nút lá: Những nút này chứa các băm của các mảnh dữ liệu cá nhân và được đặt ở mức độ dưới cùng của cây. Mỗi nút lá đại diện cho băm của một mảnh dữ liệu cụ thể trong cây Merkle.
2. Các nút nhánh: Những nút này chứa các băm kết hợp của các nút con của chúng. Ví dụ, trong một cây Merkle nhị phân (trong đó N=2), các băm của hai nút con được nối và băm lại để tạo ra băm của một nút nhánh ở mức cao hơn.
3. Nút gốc: Nút gốc nằm ở mức cao nhất của cây Merkle và đại diện cho tổng kết mật mã của toàn bộ cây. Nút này được sử dụng để xác minh tính toàn vẹn và đúng đắn của tất cả dữ liệu trong cây.

Nếu bạn đang tự hỏi làm thế nào để xây dựng một cây như vậy, nó chỉ liên quan đến hai bước đơn giản:

• Tạo nút lá: Mỗi mảnh dữ liệu được xử lý thông qua một hàm băm, và các mã băm kết quả tạo thành các nút lá. Các nút này nằm ở mức thấp nhất của cây và đại diện cho bản tóm tắt mật mã của dữ liệu.

• Kết hợp và băm: Các giá trị băm của các nút lá được nhóm lại (ví dụ, thành các cặp) và kết hợp, sau đó được băm. Quá trình này tạo ra các nút nhánh ở cấp độ tiếp theo. Quá trình tương tự được lặp lại cho các nút nhánh cho đến khi chỉ còn lại một giá trị băm duy nhất.

Hash cuối cùng nhận được ở đỉnh cây được gọi là Merkle root. Merkle Root đại diện cho bản tóm tắt mật mã của toàn bộ cây và cho phép xác minh an toàn tính toàn vẹn dữ liệu.

Làm thế nào chúng ta sử dụng các gốc Merkle để xác minh trạng thái của Ethereum?

Chứng minh Merkle giúp người Xác minh xác thực một cách hiệu quả các mảnh dữ liệu cụ thể bằng cách cung cấp một loạt các giá trị băm tạo ra một đường dẫn từ dữ liệu được nhắm mục tiêu (một nút lá) đến Gốc Merkle được lưu trữ trong tiêu đề khối. Chuỗi băm trung gian này cho phép người Xác minh xác nhận tính xác thực của dữ liệu mà không cần băm toàn bộ trạng thái.

Bắt đầu từ điểm dữ liệu cụ thể, Verifier kết hợp nó với mỗi hash “sibling” được cung cấp trong Merkle Proof và băm chúng từng bước lên cây. Quá trình này tiếp tục cho đến khi chỉ còn một hash duy nhất được tạo ra. Nếu hash tính toán này khớp với Merkle Root đã lưu trữ, dữ liệu được coi là hợp lệ; nếu không, Verifier có thể xác định rằng dữ liệu không tương ứng với trạng thái được tuyên bố.

Ví dụ: Xác minh một điểm dữ liệu với chứng minh Merkle

Hãy nói rằng chúng ta đã nhận được Dữ liệu #4 từ một RPC và muốn xác minh tính xác thực của nó bằng cách sử dụng một Chứng minh Merkle. Để làm điều này, RPC sẽ cung cấp một tập hợp các giá trị băm trên đường dẫn cần thiết để đạt đến Gốc Merkle. Đối với Dữ liệu 4 này, các giá trị băm anh em này sẽ bao gồm Hash #3, Hash #12 và Hash #5678.

1. Bắt đầu với Dữ liệu 4: Đầu tiên, chúng ta băm Dữ liệu #4 để có được Băm #4.
2. Kết hợp với Anh chị em: Sau đó, chúng tôi kết hợp Hash #4 với Hash #3 (anh chị em của nó ở mức lá) và băm chúng cùng nhau để tạo ra Hash #34.
3. Tiếp theo, chúng ta lấy Hash #34 và kết hợp với Hash #12 (là anh em cùng cấp tiếp theo) và hash chúng để lấy Hash #1234.
4. Bước cuối cùng: Cuối cùng, chúng ta kết hợp Hash #1234 với Hash #5678 (sibling cuối cùng được cung cấp) và băm chúng cùng nhau. Hash kết quả nên khớp với Merkle Root (Hash #12345678) được lưu trữ trong tiêu đề khối.

Nếu Merkle Root tính toán khớp với root trạng thái trong khối, chúng ta xác nhận rằng Dữ liệu #4 thực sự hợp lệ trong trạng thái này. Nếu không, chúng ta biết rằng dữ liệu không thuộc về trạng thái được tuyên bố, cho thấy có khả năng là đã bị can thiệp. Như bạn có thể thấy, mà không cần cung cấp các hash của tất cả dữ liệu hoặc yêu cầu Verifier phải xây dựng lại toàn bộ Merkle Tree từ đầu, Prover có thể chứng minh rằng Dữ liệu #4 tồn tại trong trạng thái và không bị thay đổi trong quá trình di chuyển—chỉ sử dụng ba hash. Đây là lý do chính tại sao Merkle Proofs được coi là hiệu quả.

Mặc dù cây Merkle không thể phủ nhận hiệu quả trong việc cung cấp xác minh dữ liệu an toàn và hiệu quả trong các hệ thống blockchain lớn như Ethereum, nhưng liệu chúng có đủ hiệu quả không? Để trả lời câu hỏi này, chúng ta phải phân tích cách hiệu suất và kích thước của cây Merkle ảnh hưởng đến mối quan hệ Chứng minh- Xác minh.

Hai yếu tố chính ảnh hưởng đến hiệu suất cây Merkle: ⌛

1. Branching Factor: Số lượng nút con trên mỗi nhánh.
2. Kích thước dữ liệu tổng cộng: Kích thước của bộ dữ liệu được biểu diễn trong cây.

Tác động của yếu tố nhánh:

Hãy sử dụng một ví dụ để hiểu rõ hơn về tác động của nó. Hệ số nhánh xác định số nhánh nảy ra từ mỗi nút trong cây.

• Nhánh nhỏ (ví dụ, cây Merkle nhị phân):
  Nếu sử dụng một cây Merkle nhị phân (hệ số nhánh là 2), kích thước chứng minh sẽ rất nhỏ, làm cho quá trình xác minh hiệu quả hơn đối với Bên xác minh. Chỉ với hai nhánh tại mỗi nút, Bên xác minh chỉ cần xử lý một băm chị em mỗi cấp độ. Điều này làm tăng tốc quá trình xác minh và giảm bớt công việc tính toán. Tuy nhiên, hệ số nhánh giảm làm tăng chiều cao của cây, yêu cầu thêm phép băm trong quá trình xây dựng cây, điều này có thể làm gánh nặng cho người xác minh.
• Số nhánh lớn hơn (ví dụ, 4):
  Một hệ số nhánh lớn hơn (ví dụ, 4) làm giảm chiều cao của cây, tạo ra một cấu trúc ngắn hơn và rộng hơn. Điều này cho phép các nút đầy đủ xây dựng cây nhanh hơn vì cần ít thao tác băm hơn. Tuy nhiên, đối với Verifier, điều này tăng số lượng sibling hash mà họ phải xử lý ở mỗi cấp độ, dẫn đến kích thước chứng minh lớn hơn. Việc có nhiều hash hơn cho mỗi bước xác minh cũng đồng nghĩa với chi phí tính toán và băng thông cao hơn cho Verifier, hiệu quả chuyển gánh nặng từ validators sang verifiers.

Tác động của tổng kích thước dữ liệu:

Khi chuỗi khối Ethereum phát triển, mỗi giao dịch, hợp đồng hoặc tương tác người dùng mới đều đóng góp vào bộ dữ liệu, cây Merkle cũng phải mở rộng. Sự phát triển này không chỉ tăng kích thước của cây mà còn ảnh hưởng đến kích thước chứng minh và thời gian xác minh.

• Full Nodes phải xử lý và cập nhật tập dữ liệu ngày càng tăng để duy trì Merkle Tree.
• Những người xác minh, trong quá trình đó, phải xác minh các bằng chứng dài hơn và phức tạp hơn khi tập dữ liệu tăng lên, đòi hỏi thời gian xử lý và băng thông bổ sung.
  Kích thước dữ liệu ngày càng tăng này làm tăng nhu cầu về cả Full Nodes và Verifiers, làm cho việc mở rộng mạng lưới hiệu quả hơn.

Tóm lại, mặc dù cây Merkle mang lại một mức độ hiệu quả, nhưng chúng không đáp ứng được một giải pháp tối ưu cho tập dữ liệu ngày càng tăng của Ethereum. Vì lí do này, trong giai đoạn The Verge, Ethereum nhằm thay thế cây Merkle bằng một cấu trúc hiệu quả hơn được gọi là Cây Verkle. Cây Verkle có tiềm năng cung cấp kích thước bằng chứng nhỏ hơn trong khi vẫn duy trì cùng mức độ bảo mật, làm cho quá trình xác minh trở nên bền vững và có thể mở rộng hơn cho cả Người chứng minh và Người xác minh.

Chương 2: Cách mà Ethereum Cách mạng hóa Khả năng xác minh - The Verge

Verge được phát triển như một cột mốc trong lộ trình của Ethereum nhằm cải thiện tính xác thực, tăng cường cấu trúc phi tập trung của blockchain và nâng cao bảo mật mạng. Một trong những mục tiêu chính của mạng Ethereum là cho phép bất kỳ ai dễ dàng chạy một trình xác thực để xác minh chuỗi, tạo ra một cấu trúc nơi mọi người có thể tham gia mà không cần tập trung quyền lực. Sự truy cập vào quá trình xác minh này là một trong những tính năng chính phân biệt blockchain với hệ thống tập trung. Trong khi các hệ thống tập trung không cung cấp khả năng xác minh, tính chính xác của một blockchain hoàn toàn nằm trong tay người dùng của nó. Tuy nhiên, để duy trì đảm bảo này, việc chạy một trình xác minh phải dễ dàng tiếp cận với tất cả mọi người - một thách thức mà, trong hệ thống hiện tại, bị giới hạn do yêu cầu lưu trữ và tính toán.

Kể từ khi chuyển sang mô hình đồng thuận Proof-of-Stake với The Merge, các nhà xác minh Ethereum đã có hai trách nhiệm chính:

1. Đảm bảo sự nhất quán: Hỗ trợ hoạt động đúng đắn của cả giao thức nhất quán xác suất và xác định và áp dụng thuật toán lựa chọn nhánh.
2. Kiểm tra độ chính xác của khối: Sau khi thực hiện các giao dịch trong một khối, xác minh rằng gốc của cây trạng thái kết quả phù hợp với gốc trạng thái được khai báo bởi người đề xuất.

Để hoàn thành trách nhiệm thứ hai, người xác thực phải có quyền truy cập vào trạng thái trước khi chặn. Điều này cho phép họ thực hiện các giao dịch của khối và lấy được trạng thái tiếp theo. Tuy nhiên, yêu cầu này đặt ra gánh nặng lớn cho người xác nhận, vì họ cần xử lý các yêu cầu lưu trữ quan trọng. Mặc dù Ethereum được thiết kế để khả thi và chi phí lưu trữ đã giảm trên toàn cầu, nhưng vấn đề là ít hơn về chi phí và nhiều hơn về sự phụ thuộc vào phần cứng chuyên dụng cho trình xác thực. The Verge nhằm mục đích vượt qua thách thức này bằng cách tạo ra một cơ sở hạ tầng nơi xác minh đầy đủ có thể được thực hiện ngay cả trên các thiết bị có bộ nhớ hạn chế, chẳng hạn như điện thoại di động, ví trình duyệt và thậm chí cả đồng hồ thông minh, cho phép trình xác thực chạy trên các thiết bị này.

Bước đầu tiên của tính xác thực: Trạng thái

Chuyển đổi sang Cây Verkle là một phần quan trọng của quá trình này. Ban đầu, The Verge tập trung vào việc thay thế cấu trúc Cây Merkle của Ethereum bằng Cây Verkle. Lý do chính để áp dụng Cây Verkle là vì Cây Merkle tạo ra một rào cản đáng kể đối với tính xác minh của Ethereum. Trong khi Cây Merkle và bằng chứng của chúng có thể hoạt động hiệu quả trong các tình huống bình thường, hiệu suất của chúng giảm đáng kể trong các tình huống xấu nhất.

Theo các tính toán của Vitalik, kích thước bằng chứng trung bình là khoảng 4 KB, nghe có vẻ dễ quản lý. Tuy nhiên, trong các kịch bản xấu nhất, kích thước bằng chứng có thể phình to lên đến 330 MB. Vâng, bạn đã đọc đúng đó—330 MB.

Sự vô hiệu tuyệt đối của cây Merkle của Ethereum trong các tình huống xấu nhất xuất phát từ hai nguyên nhân chính:

1. Sử dụng cây Hexary: Hiện tại, Ethereum đang sử dụng Cây Merkle với yếu tố nhánh là 16. Điều này có nghĩa là việc xác minh một nút duy nhất đòi hỏi cung cấp 15 băm còn lại trong nhánh. Với kích thước trạng thái của Ethereum và số lượng nhánh, điều này tạo ra một gánh nặng đáng kể trong các tình huống xấu nhất.

1. Không-Merkelization của Mã: Thay vì tích hợp mã hợp đồng vào cấu trúc cây, Ethereum chỉ đơn giản là băm mã và sử dụng giá trị kết quả như một nút. Xem xét rằng kích thước tối đa của một hợp đồng là 24 KB, phương pháp này đặt một gánh nặng đáng kể để đạt được khả năng xác minh đầy đủ.

Kích thước bằng chứng tỷ lệ thuận với hệ số phân nhánh. Giảm hệ số phân nhánh làm giảm kích thước bằng chứng. Để giải quyết những vấn đề này và cải thiện các tình huống xấu nhất, Ethereum có thể chuyển từ Hexary Trees sang Binary Merkle Trees và bắt đầu hợp nhất các mã hợp đồng. Nếu hệ số phân nhánh trong Ethereum giảm từ 16 xuống còn 2 và mã hợp đồng cũng được hợp nhất, kích thước bằng chứng tối đa có thể giảm xuống còn 10 MB. Mặc dù đây là một cải tiến đáng kể, nhưng điều quan trọng cần lưu ý là chi phí này chỉ áp dụng cho việc xác minh một phần dữ liệu. Ngay cả một giao dịch đơn giản truy cập nhiều mẩu dữ liệu cũng sẽ yêu cầu bằng chứng lớn hơn. Với số lượng giao dịch trên mỗi khối và trạng thái phát triển liên tục của Ethereum, giải pháp này, mặc dù tốt hơn, vẫn không hoàn toàn khả thi.

Vì những lý do này, cộng đồng Ethereum đã đề xuất hai giải pháp khác nhau để giải quyết vấn đề:

1. Cây Verkle
2. STARK Proofs + Binary Merkle Trees

Verkle Trees & Vector Commitments

Cây Verkle, như tên gọi của nó, là cấu trúc cây tương tự như Cây Merkle. Tuy nhiên, sự khác biệt quan trọng nhất nằm ở tính hiệu quả mà chúng cung cấp trong quá trình xác minh. Trong Cây Merkle, nếu một nhánh chứa 16 mảnh dữ liệu và chúng ta muốn xác minh chỉ một trong số chúng, một chuỗi băm bao phủ 15 mảnh dữ liệu còn lại cũng phải được cung cấp. Điều này tăng đáng kể gánh nặng tính toán của quá trình xác minh và dẫn đến kích thước bằng chứng lớn.

Ngược lại, Cây Verkle sử dụng một cấu trúc chuyên biệt được biết đến là “Cam kết Vector dựa trên đường cong Elliptic”, cụ thể hơn là Cam kết Vector dựa trên Biện pháp Sản phẩm Nội tại (IPA). Vector về cơ bản là một danh sách các phần tử dữ liệu được tổ chức theo một chuỗi cụ thể. Trạng thái của Ethereum có thể được coi như là một vector: một cấu trúc trong đó nhiều phần tử dữ liệu được lưu trữ theo một thứ tự cụ thể, với mỗi phần tử đều quan trọng. Trạng thái này bao gồm các thành phần dữ liệu khác nhau như địa chỉ, mã hợp đồng và thông tin lưu trữ, trong đó thứ tự của các phần tử này đóng một vai trò quan trọng trong việc truy cập và xác minh.

Vector Commitments là các phương pháp mật mã được sử dụng để chứng minh và xác minh các phần tử dữ liệu trong một tập dữ liệu. Những phương pháp này cho phép xác minh cả sự tồn tại và thứ tự của mỗi phần tử trong tập dữ liệu một cách đồng thời. Ví dụ, Merkle Proofs, được sử dụng trong Merkle Trees, cũng có thể coi là một hình thức của Vector Commitment. Trong khi Merkle Trees yêu cầu tất cả các chuỗi hash liên quan để xác minh một phần tử, cấu trúc này tự nhiên chứng minh rằng tất cả các phần tử của một vector được kết nối theo một trình tự cụ thể.

Khác với cây Merkle, cây Verkle sử dụng cam kết vector dựa trên đường cong elliptic mang lại hai lợi ích quan trọng:

• Các cam kết vector dựa trên đường cong elip loại bỏ nhu cầu về chi tiết của các phần tử khác ngoài dữ liệu được xác minh. Trong cây Merkle với hệ số nhánh là 16, việc xác minh một nhánh duy nhất đòi hỏi cung cấp 15 giá trị băm khác. Với kích thước rất lớn của trạng thái Ethereum, bao gồm nhiều nhánh, điều này tạo ra một hiệu suất không hiệu quả đáng kể. Tuy nhiên, cam kết vector dựa trên đường cong elip loại bỏ sự phức tạp này, cho phép xác minh với ít dữ liệu và công sức tính toán hơn.
• Thông qua đa chứng minh, các chứng minh được tạo ra bởi các cam kết vectơ dựa trên đường cong elip có thể được nén thành một bằng chứng duy nhất, có kích thước không đổi. Trạng thái của Ethereum không chỉ lớn mà còn liên tục phát triển, đồng nghĩa với việc số lượng nhánh cần xác minh để truy cập Merkle Root tăng lên theo thời gian. Tuy nhiên, với Verkle Trees, chúng ta có thể “nén” các chứng minh cho mỗi nhánh thành một bằng chứng có kích thước không đổi duy nhất bằng phương pháp được nêu chi tiết trong Bài viết của Dankrad FeistĐiều này cho phép Verifiers xác thực toàn bộ cây bằng một chứng minh nhỏ thay vì xác minh từng nhánh một. Điều này cũng có nghĩa là Verkle Trees không bị ảnh hưởng bởi sự phát triển của trạng thái Ethereum.

Những tính năng của cam kết vector dựa trên đường cong elip giúp giảm đáng kể lượng dữ liệu cần thiết cho quá trình xác minh, cho phép cây Verkle tạo ra các bằng chứng nhỏ gọn, kích thước không đổi ngay cả trong các tình huống xấu nhất. Điều này giảm thiểu overhead dữ liệu và thời gian xác minh, cải thiện hiệu suất của các mạng quy mô lớn như Ethereum. Kết quả là, việc sử dụng cam kết vector dựa trên đường cong elip trong cây Verkle giúp việc xử lý trạng thái mở rộng của Ethereum trở nên dễ quản lý và hiệu quả hơn.

Giống như tất cả các đổi mới khác, Cây Verkle cũng có nhược điểm của chúng. Một trong những hạn chế chính của chúng là chúng phụ thuộc vào mật mã đường cong elip, mà có thể bị tấn công bởi máy tính lượng tử. Máy tính lượng tử có sức mạnh tính toán hơn rất nhiều so với các phương pháp cổ điển, tạo ra mối đe dọa đáng kể đối với các giao thức mật mã dựa trên đường cong elip. Các thuật toán lượng tử có thể phá hoặc làm suy yếu hệ thống mật mã này, gây lo ngại về an ninh dài hạn của Cây Verkle.

Vì lý do này, mặc dù Cây Verkle đề xuất một giải pháp hứa hẹn đối với việc không có trạng thái, nhưng chúng không phải là phương pháp sửa chữa cuối cùng. Tuy nhiên, những con số như Dankrad Feist đã nhấn mạnh rằng, trong khi cần phải xem xét cẩn thận khi tích hợp mật mã chống lại lượng tử vào Ethereum, đáng lưu ý rằng các cam kết KZG hiện đang được sử dụng cho các khối trong Ethereum cũng không chống lại lượng tử. Do đó, Cây Verkle có thể phục vụ như một giải pháp tạm thời, cung cấp thêm thời gian cho mạng để phát triển các phương án thay thế mạnh mẽ hơn.

Chứng minh STARK + Cây Merkle nhị phân

Verkle Trees cung cấp kích thước bằng chứng nhỏ hơn và quy trình xác minh hiệu quả so với Merkle Trees, giúp quản lý trạng thái ngày càng phát triển của Ethereum dễ dàng hơn. Nhờ các cam kết vectơ dựa trên đường cong Elliptic, các bằng chứng quy mô lớn có thể được tạo ra với dữ liệu ít hơn đáng kể. Tuy nhiên, bất chấp những lợi thế ấn tượng của chúng, lỗ hổng của Verkle Trees đối với máy tính lượng tử khiến chúng chỉ là một giải pháp tạm thời. Trong khi cộng đồng Ethereum coi Verkle Trees là một công cụ ngắn hạn để câu giờ, trọng tâm dài hạn là chuyển sang các giải pháp kháng lượng tử. Đây là nơi STARK Proofs và Binary Merkle Trees trình bày một giải pháp thay thế mạnh mẽ để xây dựng cơ sở hạ tầng xác minh mạnh mẽ hơn cho tương lai.

Trong quá trình xác minh trạng thái của Ethereum, hệ số nhánh của Cây Merkle có thể được giảm (từ 16 xuống còn 2) bằng cách sử dụng Cây Merkle Nhị phân. Thay đổi này là một bước quan trọng để giảm kích thước chứng minh và làm cho quá trình xác minh hiệu quả hơn. Tuy nhiên, ngay cả trong trường hợp xấu nhất, kích thước chứng minh vẫn có thể đạt đến 10 MB, đó là một số lượng đáng kể. Đây là nơi mà Chứng minh STARK đóng vai trò, nén các Chứng minh Merkle Nhị phân lớn này chỉ còn 100-300 kB.

Tối ưu hóa này đặc biệt quan trọng khi xem xét các ràng buộc của việc vận hành các validator trên các thiết bị hoặc thiết bị có phần cứng giới hạn, đặc biệt nếu bạn cân nhắc rằng tốc độ tải và tải trung bình toàn cầu của di động là khoảng 7.625 MB/s và 1.5 MB/s, tương ứng. Người dùng có thể xác minh giao dịch với bằng chứng nhỏ, di động mà không cần truy cập vào trạng thái đầy đủ và các validator có thể thực hiện nhiệm vụ xác minh khối mà không cần lưu trữ toàn bộ trạng thái.

Phương pháp hai lợi ích này giảm băng thông và yêu cầu lưu trữ cho các bộ xác minh, đồng thời tăng tốc quá trình xác minh, ba cải tiến quan trọng này ủng hộ trực tiếp cho tầm nhìn về khả năng mở rộng của Ethereum.

Những thách thức chính cho các chứng minh STARK:

1. Tải trọng tính toán cao cho Provers: \
   Quá trình tạo ra các bằng chứng STARK đòi hỏi tính toán mạnh mẽ, đặc biệt là ở phía người chứng minh, điều này có thể tăng chi phí vận hành.
2. Hiệu suất không cao trong chứng minh dữ liệu nhỏ:

Mặc dù chứng minh STARK vượt trội trong việc xử lý các bộ dữ liệu lớn, nhưng chúng không hiệu quả khi chứng minh số lượng dữ liệu nhỏ, điều này có thể làm trở ngại cho việc áp dụng chúng trong một số tình huống nhất định. Khi xử lý các chương trình liên quan đến các bước nhỏ hoặc bộ dữ liệu nhỏ, kích thước chứng minh tương đối lớn của STARKs có thể làm cho chúng ít thực tế hoặc hiệu quả về chi phí.

Bảo mật lượng tử đến với một chi phí: Tải trọng tính toán từ phía Prover

Một Merkle Proof của một khối có thể bao gồm khoảng 330.000 băm, và trong trường hợp xấu nhất, số này có thể tăng lên 660.000. Trong những trường hợp như vậy, một chứng minh STARK sẽ cần xử lý khoảng 200.000 băm mỗi giây.

Đây là nơi mà các hàm băm thân thiện với zk như Poseidon được đưa vào trò chơi, được tối ưu hóa đặc biệt cho các chứng minh STARK để giảm tải này. Poseidon được thiết kế để hoạt động một cách mượt mà hơn với ZK-proofs so với các thuật toán băm truyền thống như SHA256 và Keccak. Lý do chính cho tính tương thích này nằm ở cách các thuật toán băm truyền thống hoạt động: chúng xử lý đầu vào dưới dạng dữ liệu nhị phân (0 và 1). Trong khi đó, ZK-proofs làm việc với các trường nguyên tố, cấu trúc toán học khác biệt căn bản. Tình huống này tương tự như máy tính hoạt động theo hệ nhị phân trong khi con người sử dụng hệ thập phân trong cuộc sống hàng ngày. Chuyển đổi dữ liệu dựa trên bit thành các định dạng tương thích với ZK đòi hỏi các tài nguyên tính toán đáng kể. Poseidon giải quyết vấn đề này bằng cách hoạt động tự nhiên trong các trường nguyên tố, giúp tăng tốc đáng kể quá trình tích hợp với ZK-proofs.

Tuy nhiên, vì Poseidon là một hàm băm tương đối mới, nó đòi hỏi phân tích bảo mật sâu rộng hơn để thiết lập mức độ tin cậy tương tự như các hàm băm truyền thống như SHA256 và Keccak. Để đạt được điều này, các sáng kiến như Chương trình Phân tích Poseidon Cryptanalysis, được ra mắt bởi Ethereum Foundation, mời các chuyên gia kiểm tra và phân tích một cách nghiêm ngặt về an ninh của Poseidon, đảm bảo rằng nó có thể chịu được sự kiểm tra từ các bên đối địch và trở thành một tiêu chuẩn mạnh mẽ cho các ứng dụng mật mã. Trong khi đó, các chức năng cũ như SHA256 và Keccak đã được kiểm tra một cách rộng rãi và có một lịch sử an ninh được chứng minh nhưng không phù hợp với ZK, dẫn đến sự giảm hiệu suất khi sử dụng với chứng minh STARK.

Ví dụ, các chứng minh STARK sử dụng các hàm băm truyền thống này hiện chỉ có thể xử lý từ 10.000 đến 30.000 hàm băm. May mắn thay, các tiến bộ trong công nghệ STARK cho thấy khả năng xử lý này có thể sớm tăng lên từ 100.000 đến 200.000 hàm băm, cải thiện đáng kể hiệu suất của chúng.

Độ không hiệu quả của STARKs trong chứng minh dữ liệu nhỏ

Trong khi STARK proofs vượt trội về khả năng mở rộng và tính minh bạch đối với các tập dữ liệu lớn, chúng có nhược điểm khi làm việc với các phần tử dữ liệu nhỏ và rất nhiều. Trong các tình huống này, dữ liệu được chứng minh thường nhỏ, nhưng nhu cầu về nhiều chứng minh vẫn không thay đổi. Ví dụ bao gồm:

1. Xác thực giao dịch sau AA: \
   Với Account Abstraction (AA), ví có thể trỏ đến mã hợp đồng, vượt qua hoặc tùy chỉnh các bước như kiểm tra nonce và chữ ký, hiện tại đang bắt buộc trong Ethereum. Tuy nhiên, tính linh hoạt này trong việc xác nhận yêu cầu kiểm tra mã hợp đồng hoặc dữ liệu liên quan khác trong trạng thái để chứng minh tính hợp lệ của giao dịch.
2. Cuộc gọi RPC của khách hàng nhẹ: \
   Các máy khách nhẹ truy vấn dữ liệu trạng thái từ mạng (ví dụ, trong yêu cầu eth_call) mà không chạy một nút đầy đủ. Để đảm bảo tính chính xác của trạng thái này, bằng chứng phải hỗ trợ dữ liệu được truy vấn và xác nhận rằng nó khớp với trạng thái hiện tại của mạng.
3. Inclusion lists: \
   Những validator nhỏ hơn có thể sử dụng cơ chế danh sách bao gồm để đảm bảo giao dịch được bao gồm trong khối tiếp theo, giới hạn sự ảnh hưởng của những nhà sản xuất khối mạnh mẽ. Tuy nhiên, việc xác minh việc bao gồm các giao dịch này đòi hỏi phải xác minh tính chính xác của chúng.

Trong các trường hợp sử dụng như vậy, chứng minh STARK không mang lại nhiều lợi ích. STARKs, nhấn mạnh tính mở rộng (như đã được nhấn mạnh bởi chữ “S” trong tên của họ), hoạt động tốt cho các tập dữ liệu lớn nhưng gặp khó khăn với các tình huống dữ liệu nhỏ. Ngược lại, SNARKs, được thiết kế để ngắn gọn (như đã được nhấn mạnh bởi chữ “S” trong tên của họ), tập trung vào việc tối thiểu hóa kích thước chứng minh, mang lại lợi thế rõ ràng trong môi trường có ràng buộc về băng thông hoặc lưu trữ.

Chứng minh STARK thường có kích thước khoảng 40-50 KB, khoảng 175 lần lớn hơn chứng minh SNARK chỉ có 288 byte. Sự khác biệt về kích thước này làm tăng thời gian xác minh và chi phí mạng. Lý do chính khiến cho chứng minh STARK lớn hơn là sự phụ thuộc vào tính minh bạch và cam kết đa thức để đảm bảo tính mở rộng, điều này mang lại chi phí hiệu suất trong các trường hợp dữ liệu nhỏ. Trong những trường hợp như vậy, các phương pháp nhanh hơn và tiết kiệm không gian như Chứng minh Merkle có thể phù hợp hơn. Chứng minh Merkle cung cấp chi phí tính toán thấp và cập nhật nhanh, thích hợp cho những tình huống như vậy.

Tuy nhiên, chứng minh STARK vẫn rất quan trọng đối với tương lai không có trạng thái của Ethereum do tính bảo mật vượt trội của chúng trước các tấn công từ các máy tính lượng tử.

Như tóm tắt trong bảng, Ethereum có bốn con đường tiềm năng để lựa chọn:

• Cây Verkle
  1. Verkle Trees đã nhận được sự hỗ trợ rộng rãi từ cộng đồng Ethereum, với các cuộc họp hai tuần một lần được tổ chức để tạo điều kiện cho sự phát triển của họ. Nhờ công việc và thử nghiệm nhất quán này, Verkle Trees nổi bật là giải pháp trưởng thành và được nghiên cứu kỹ lưỡng nhất trong số các lựa chọn thay thế hiện tại. Hơn nữa, các đặc tính đồng cấu phụ gia của chúng loại bỏ nhu cầu tính toán lại mọi nhánh để cập nhật gốc trạng thái, không giống như Merkle Trees, làm cho Verkle Trees trở thành một lựa chọn hiệu quả hơn. So với các giải pháp khác, Verkle Trees nhấn mạnh sự đơn giản, tuân thủ các nguyên tắc kỹ thuật như “giữ cho nó đơn giản” hoặc “đơn giản là tốt nhất”. Sự đơn giản này tạo điều kiện cho cả việc tích hợp vào Ethereum và phân tích bảo mật.
  2. Tuy nhiên, Verkle Trees không an toàn lượng tử, điều này ngăn cản chúng trở thành một giải pháp lâu dài. Nếu được tích hợp vào Ethereum, công nghệ này có thể sẽ cần phải được thay thế trong tương lai khi các giải pháp kháng lượng tử được yêu cầu. Ngay cả Vitalik cũng xem Verkle Trees như một biện pháp tạm thời để câu giờ cho STARK và các công nghệ khác trưởng thành. Ngoài ra, các cam kết vectơ dựa trên đường cong elip được sử dụng trong Verkle Trees áp đặt tải tính toán cao hơn so với các hàm băm đơn giản. Các phương pháp tiếp cận dựa trên hàm băm có thể cung cấp thời gian đồng bộ hóa nhanh hơn cho các nút đầy đủ. Hơn nữa, sự phụ thuộc vào nhiều hoạt động 256-bit làm cho Verkle Trees khó chứng minh hơn bằng cách sử dụng SNARK trong các hệ thống chứng minh hiện đại, làm phức tạp các nỗ lực trong tương lai để giảm kích thước bằng chứng.

Tuy nhiên, điều quan trọng cần lưu ý là Cây Verkle, do không phụ thuộc vào việc băm, có khả năng chứng minh đáng kể hơn Cây Merkle.

• STARKs + Hàm băm Bảo thủ
  1. Kết hợp STARKs với các hàm băm bảo thủ đã được thiết lập tốt như SHA256 hoặc BLAKE cung cấp một giải pháp mạnh mẽ gia tăng hệ thống bảo mật của Ethereum. Các hàm băm này đã được sử dụng rộng rãi và được kiểm tra kỹ lưỡng trong cả lĩnh vực học thuật và thực tiễn. Hơn nữa, tính chống lại lượng tử của chúng nâng cao sự kiên cường của Ethereum đối mặt với các mối đe dọa trong tương lai từ máy tính lượng tử. Đối với các tình huống quan trọng về bảo mật, sự kết hợp này cung cấp một nền tảng đáng tin cậy.
  2. Tuy nhiên, việc sử dụng các hàm băm bảo thủ trong các hệ thống STARK đưa ra những hạn chế đáng kể về hiệu suất. Các yêu cầu tính toán của các hàm băm này dẫn đến độ trễ chứng minh cao, với việc tạo bằng chứng mất hơn 10 giây. Đây là một bất lợi lớn, đặc biệt là trong các tình huống như xác thực khối đòi hỏi độ trễ thấp. Trong khi những nỗ lực như đề xuất khí đốt đa chiều cố gắng điều chỉnh độ trễ trường hợp xấu nhất và trường hợp trung bình, kết quả còn hạn chế. Ngoài ra, mặc dù các phương pháp tiếp cận dựa trên hàm băm có thể tạo điều kiện cho thời gian đồng bộ hóa nhanh hơn, nhưng hiệu quả của chúng có thể không phù hợp với các mục tiêu khả năng mở rộng rộng hơn của STARK. Thời gian tính toán dài của các hàm băm truyền thống làm giảm hiệu quả thực tế và hạn chế khả năng ứng dụng của chúng.
• STARKs + Hàm băm Tương đối Mới
  1. STARKs kết hợp với các hàm băm thế hệ mới thân thiện với STARK (ví dụ như Poseidon) cải thiện đáng kể hiệu suất của công nghệ này. Các hàm băm này được thiết kế để tích hợp một cách mượt mà với hệ thống STARK và giảm đáng kể thời gian chờ của bằng chứng. Không giống như các hàm băm truyền thống, chúng cho phép tạo ra bằng chứng chỉ trong chỉ 1-2 giây. Hiệu suất và chi phí tính toán thấp của chúng nâng cao khả năng mở rộng của STARKs, khiến chúng rất hiệu quả trong xử lý tập dữ liệu lớn. Khả năng này khiến chúng trở nên hấp dẫn đặc biệt đối với các ứng dụng yêu cầu hiệu suất cao.
  2. Tuy nhiên, tính mới mẻ so với các hàm băm này đòi hỏi phân tích và kiểm tra bảo mật toàn diện. Thiếu kiểm tra toàn diện đem lại các rủi ro khi xem xét việc triển khai chúng trong các hệ sinh thái quan trọng như Ethereum. Ngoài ra, vì các hàm băm này chưa được sử dụng rộng rãi, các quy trình kiểm tra và xác minh cần thiết có thể làm trì hoãn mục tiêu xác minh của Ethereum. Thời gian cần thiết để đảm bảo an ninh toàn diện có thể làm cho tùy chọn này ít hấp dẫn trong tương lai ngắn hạn, có thể làm trì hoãn khả năng mở rộng và khát vọng xác minh của Ethereum.
• Cây Merkle dựa trên lưới tinh thể
  1. Cây Merkle dựa trên lưới cung cấp một giải pháp tương lai kết hợp bảo mật với hiệu suất cập nhật của Cây Verkle. Cấu trúc này giải quyết nhược điểm của cả Cây Verkle và STARKs và được coi là một lựa chọn tiềm năng trong dài hạn. Với thiết kế dựa trên lưới, chúng cung cấp khả năng chống lại các mối đe dọa của máy tính lượng tử, phù hợp với sự tập trung của Ethereum vào việc bảo vệ tương lai hệ sinh thái của nó. Hơn nữa, bằng cách giữ lại những lợi ích về cập nhật của Cây Verkle, chúng nhằm cung cấp bảo mật nâng cao mà không đánh đổi hiệu suất.
  2. Tuy nghiên cứu về Cây Merkle dựa trên lưới mạng vẫn đang ở giai đoạn đầu và chủ yếu là lý thuyết. Điều này tạo ra sự không chắc chắn đáng kể về việc triển khai và hiệu suất thực tế của chúng. Việc tích hợp một giải pháp như vậy vào Ethereum sẽ yêu cầu nghiên cứu và phát triển đáng kể, cũng như kiểm tra nghiêm ngặt để xác minh những lợi ích tiềm năng của nó. Những sự không chắc chắn và sự phức tạp về cơ sở hạ tầng này khiến cho Cây Merkle dựa trên lưới mạng khó có thể là một lựa chọn khả thi cho Ethereum trong tương lai gần, có thể làm trì hoãn tiến trình đạt được mục tiêu xác minh của mạng.

Có điều gì về việc thực hiện: Chứng minh tính hợp lệ của việc thực thi EVM

Mọi thứ chúng ta đã thảo luận cho đến nay xoay quanh việc loại bỏ nhu cầu của người xác nhận để lưu trữ trạng thái trước đó, mà họ sử dụng để chuyển từ một trạng thái sang trạng thái tiếp theo. Mục tiêu là tạo ra một môi trường phân quyền hơn nơi mà người xác nhận có thể thực hiện nhiệm vụ của họ mà không cần duy trì terabytes dữ liệu trạng thái. Ngay cả với các giải pháp chúng ta đã đề cập, người xác nhận cũng không cần phải lưu trữ toàn bộ trạng thái, vì họ sẽ nhận tất cả dữ liệu cần thiết để thực thi thông qua những người chứng kiến được bao gồm trong khối. Tuy nhiên, để chuyển sang trạng thái tiếp theo—và qua đó xác minh stateRoot trên đỉnh của khối—người xác nhận vẫn phải thực hiện STF một cách tự mình. Yêu cầu này, lần lượt, đặt ra một thách thức khác đối với tính phân quyền và phân quyền của Ethereum.

Ban đầu, The Verge được tưởng tượng là một cột mốc tập trung duy nhất vào việc chuyển từ cây trạng thái của Ethereum từ Cây Merkle sang Cây Verkle để cải thiện khả năng xác minh trạng thái. Tuy nhiên, theo thời gian, nó đã phát triển thành một sáng kiến rộng lớn hơn nhằm mục tiêu cải thiện khả năng xác minh của các chuyển đổi trạng thái và sự đồng thuận. Trong một thế giới mà bộ ba Trạng thái, Thực thi và Đồng thuận hoàn toàn có thể xác minh, các nhà xác minh Ethereum có thể hoạt động trên bất kỳ thiết bị nào có kết nối internet có thể được phân loại là Máy khách Nhẹ. Điều này sẽ đưa Ethereum gần hơn đến việc đạt được tầm nhìn của nó về “sự phân quyền thực sự.”

Định nghĩa vấn đề là gì?

Như chúng tôi đã đề cập trước đó, các validator thực thi một hàm được gọi là STF (State Transition Function) mỗi 12 giây. Hàm này nhận đầu vào là trạng thái trước đó và một khối và sản xuất trạng thái tiếp theo là đầu ra. Các validator phải thực thi hàm này mỗi khi một khối mới được đề xuất và xác minh rằng mã băm đại diện cho trạng thái trên đỉnh khối - thường được gọi là rễ trạng thái - là chính xác.

Yêu cầu hệ thống cao để trở thành một người xác minh chủ yếu bắt nguồn từ nhu cầu thực hiện quá trình này một cách hiệu quả.

Nếu bạn muốn biến một tủ lạnh thông minh - có, thậm chí là một cái tủ lạnh - thành một nhà xác nhận Ethereum với sự trợ giúp của một số phần mềm đã được cài đặt, bạn sẽ đối mặt với hai rào cản chính:

1. Tủ lạnh của bạn có thể không có internet đủ nhanh, điều đó có nghĩa là nó sẽ không thể tải xuống dữ liệu và bằng chứng cần thiết để thực thi ngay cả với các giải pháp xác minh trạng thái chúng ta đã thảo luận cho đến nay.
2. Ngay cả khi nó có quyền truy cập vào dữ liệu cần thiết cho STF, nó cũng sẽ không có sức mạnh tính toán cần thiết để thực hiện từ đầu đến cuối hoặc xây dựng một cây trạng thái mới.

Để giải quyết các vấn đề gây ra bởi Light Clients không có quyền truy cập vào trạng thái trước đó hoặc toàn bộ khối cuối cùng, Verge đề xuất rằng người đề xuất nên thực hiện thực thi và sau đó đính kèm một chứng minh vào khối. Chứng minh này sẽ bao gồm sự chuyển tiếp từ gốc trạng thái trước đó đến gốc trạng thái tiếp theo cũng như băm của khối. Với điều này, Light Clients có thể xác thực sự chuyển tiếp trạng thái chỉ bằng ba băm 32 byte, mà không cần cần một chứng minh zk.

Tuy nhiên, vì bằng chứng này hoạt động thông qua các băm, nên nó sẽ không chính xác nếu nói nó chỉ xác nhận sự chuyển trạng thái. Ngược lại, bằng chứng được đính kèm vào khối phải xác nhận đồng thời nhiều thứ khác nhau:

Gốc trạng thái trong khối trước đó = S, Gốc trạng thái trong khối tiếp theo = S + 1, Hash khối = H

1. Khối chính nó phải hợp lệ, và chứng minh trạng thái bên trong nó — dù là Chứng minh Verkle hay STARKs — phải xác minh chính xác dữ liệu đi kèm với khối.
   Đơn giản: Xác thực khối và chứng minh trạng thái đi kèm.
2. Khi STF được thực hiện bằng cách sử dụng dữ liệu cần thiết để thực hiện và được bao gồm trong khối tương ứng với H, dữ liệu mà phải thay đổi trong trạng thái phải được cập nhật đúng cách.
   Tóm lại: Xác thực của quá trình chuyển trạng thái.
3. Khi cây trạng thái mới được xây dựng lại với dữ liệu đã được cập nhật đúng, giá trị gốc của nó phải khớp với S + 1.
   Tóm lại: Xác thực quá trình xây dựng cây.

Trong phân ưu người chứng minh - người xác minh mà chúng tôi đã đề cập trước đó, có thể nói rằng thường có sự cân đối tính toán giữa hai diễn viên. Trong khi khả năng của các chứng minh cần thiết để làm cho STF có thể xác minh để xác nhận đồng thời nhiều điều cung cấp lợi thế đáng kể cho người xác minh, nó cũng chỉ ra rằng việc tạo ra các chứng minh như vậy để đảm bảo tính đúng đắn của việc thực hiện sẽ khá thách thức đối với người chứng minh. Với tốc độ hiện tại của Ethereum, một khối Ethereum cần được chứng minh trong vòng dưới 4 giây. Tuy nhiên, ngay cả với người chứng minh EVM nhanh nhất hiện nay, chúng ta chỉ có thể chứng minh một khối trung bình trong khoảng 15 giây.[1]

Nói vậy, có ba con đường rõ ràng mà chúng ta có thể đi để vượt qua thách thức lớn này:

1. Song song hóa trong chứng minh & Tổng hợp: Một trong những lợi thế đáng kể của các chứng minh ZK là khả năng tổng hợp chúng. Khả năng kết hợp nhiều chứng minh thành một chứng minh nhỏ gọn duy nhất cung cấp hiệu suất đáng kể về thời gian xử lý. Điều này không chỉ giảm tải trên mạng mà còn tăng tốc quá trình xác minh một cách phi tập trung. Đối với một mạng lớn như Ethereum, nó cho phép tạo ra các chứng minh hiệu quả hơn cho mỗi khối.

Trong quá trình tạo chứng minh, mỗi phần nhỏ của quá trình thực thi (ví dụ, các bước tính toán hoặc truy cập dữ liệu) có thể được chứng minh một cách cá nhân, và những chứng minh này sau đó có thể được kết hợp thành một cấu trúc duy nhất. Với cơ chế chính xác, cách tiếp cận này cho phép chứng minh của một khối được tạo ra nhanh chóng và theo cách phi tập trung từ nhiều nguồn khác nhau (ví dụ, hàng trăm GPU). Điều này tăng cường hiệu suất đồng thời cũng đóng góp vào mục tiêu phi tập trung bằng cách thu hút một nhóm người tham gia rộng lớn hơn.

1. Sử dụng Hệ thống Chứng minh Tối ưu hóa: Hệ thống chứng minh thế hệ mới có tiềm năng làm cho quá trình tính toán của Ethereum nhanh hơn và hiệu quả hơn. Các hệ thống tiên tiến như gate,Orion, Nhị phân, và GKRcó thể giảm đáng kể thời gian chứng minh cho các tính toán chung. Các hệ thống này nhằm vượt qua các hạn chế của các công nghệ hiện tại, tăng tốc độ xử lý trong khi tiêu thụ ít tài nguyên hơn. Đối với một mạng lưới tập trung vào khả năng mở rộng và hiệu suất như Ethereum, những tối ưu hóa như vậy mang lại lợi thế đáng kể. Tuy nhiên, việc triển khai đầy đủ của những hệ thống mới này đòi hỏi kiểm tra toàn diện và nỗ lực tương thích trong hệ sinh thái.
2. Thay Đổi Chi Phí Gas: Lịch sử, chi phí gas cho các hoạt động trên Máy Ảo Ethereum (EVM) thường được xác định dựa trên chi phí tính toán của chúng. Tuy nhiên, ngày nay, một chỉ số khác đã trở nên quan trọng hơn: độ phức tạp của bằng chứng. Trong khi một số hoạt động tương đối dễ chứng minh, những hoạt động khác có cấu trúc phức tạp hơn và mất thời gian lâu hơn để xác minh. Điều chỉnh chi phí gas không chỉ dựa trên nỗ lực tính toán mà còn dựa trên độ khó của việc chứng minh hoạt động là quan trọng để nâng cao cả tính bảo mật và hiệu quả của mạng.

Phương pháp này có thể giảm thiểu khoảng cách giữa các kịch bản xấu nhất và trung bình, từ đó tạo ra hiệu suất nhất quán hơn. Ví dụ, các hoạt động khó chứng minh có thể có chi phí gas cao hơn, trong khi những hoạt động dễ chứng minh có thể có chi phí thấp hơn. Ngoài ra, việc thay thế các cấu trúc dữ liệu của Ethereum (như cây trạng thái hoặc danh sách giao dịch) bằng các lựa chọn thân thiện với STARK có thể giúp tăng tốc quá trình chứng minh. Những thay đổi như vậy sẽ giúp Ethereum đạt được mục tiêu về khả năng mở rộng và bảo mật, đồng thời làm cho tầm nhìn về khả năng xác minh của nó trở nên thực tế hơn.

Nỗ lực của Ethereum để cho phép chứng minh thực hiện đại diện cho một cơ hội quan trọng để đạt được mục tiêu xác minh của nó. Tuy nhiên, để đạt được mục tiêu này không chỉ đòi hỏi sự đổi mới kỹ thuật mà còn đòi hỏi sự nỗ lực kỹ thuật và quyết định quan trọng trong cộng đồng. Việc làm cho các quá trình thực hiện có thể xác minh trên Layer 1 phải đạt được sự cân bằng giữa việc tiếp cận một cơ sở người dùng rộng lớn và duy trì tính phân quyền và phù hợp với cơ sở hạ tầng hiện tại. Việc thiết lập sự cân bằng này tăng độ phức tạp của các phương pháp được sử dụng để chứng minh các hoạt động trong quá trình thực hiện, nhấn mạnh sự cần thiết của sự tiến bộ như tạo ra chứng minh song song. Ngoài ra, yêu cầu cơ sở hạ tầng của các công nghệ này (ví dụ, bảng tra cứu) phải được thực thi và hoạt động, điều đó vẫn đòi hỏi nghiên cứu và phát triển đáng kể.

Tuy nhiên, các mạch chuyên dụng (ví dụ: ASIC, FPGA, GPU) được thiết kế đặc biệt cho một số nhiệm vụ cụ thể mang lại tiềm năng đáng kể để tăng tốc quá trình tạo ra chứng minh. Những giải pháp này cung cấp hiệu suất cao hơn đáng kể so với phần cứng truyền thống và có thể tăng tốc quá trình thực thi. Tuy nhiên, mục tiêu phân tán của Ethereum ở mức Layer 1 ngăn chặn việc truy cập vào phần cứng này chỉ cho một nhóm người lựa chọn. Do đó, dự kiến ​​rằng những giải pháp này sẽ được sử dụng rộng rãi hơn trong các hệ thống Layer 2. Tuy nhiên, cộng đồng cũng phải đạt được sự nhất trí về yêu cầu phần cứng cho việc tạo ra chứng minh. Một câu hỏi thiết kế quan trọng nảy sinh: liệu việc tạo ra chứng minh có nên hoạt động trên phần cứng cho người tiêu dùng như laptop cao cấp, hay yêu cầu cơ sở hạ tầng công nghiệp? Câu trả lời này tạo nên kiến ​​trúc toàn bộ của Ethereum - cho phép tối ưu hóa mạnh mẽ cho các giải pháp Layer 2 trong khi đòi hỏi phương pháp cẩn thận hơn cho Layer 1.

Cuối cùng, việc thực hiện các bằng chứng thực thi được gắn trực tiếp với các mục tiêu lộ trình khác của Ethereum. Việc giới thiệu các bằng chứng hợp lệ sẽ không chỉ hỗ trợ các khái niệm như vô quốc tịch mà còn tăng cường sự phân cấp của Ethereum bằng cách làm cho các lĩnh vực như đặt cọc một mình dễ tiếp cận hơn. Mục tiêu là cho phép đặt cọc trên ngay cả những thiết bị có thông số kỹ thuật thấp nhất. Ngoài ra, việc tái cấu trúc chi phí khí đốt trên EVM dựa trên độ khó tính toán và khả năng chứng minh có thể giảm thiểu khoảng cách giữa các tình huống trung bình và trường hợp xấu nhất. Tuy nhiên, những thay đổi như vậy có thể phá vỡ khả năng tương thích ngược với hệ thống hiện tại và buộc các nhà phát triển phải viết lại mã của họ. Vì lý do này, việc thực hiện các bằng chứng thực thi không chỉ là một thách thức kỹ thuật mà còn là một hành trình phải được thiết kế để duy trì các giá trị lâu dài của Ethereum.

Bước cuối cùng cho tính xác minh đầy đủ thực sự: Consensus

Cơ chế đồng thuận của Ethereum cố gắng thiết lập một cân bằng duy nhất giữa việc bảo tồn tính phi tập trung và truy cập đồng thời đạt được mục tiêu xác minh. Trong khuôn khổ này, các phương pháp đồng thuận xác suất và xác định cung cấp những lợi thế và thách thức khác nhau.

Sự đồng thuận xác suất được xây dựng trên mô hình truyền thông truyền đồn. Trong mô hình này, thay vì trực tiếp giao tiếp với tất cả các nút đại diện cho mạng, một nút chia sẻ thông tin với một tập hợp ngẫu nhiên được chọn 64 hoặc 128 nút. Lựa chọn chuỗi của một nút dựa trên thông tin hạn chế này, điều này đưa ra khả năng sai sót. Tuy nhiên, theo thời gian, khi blockchain tiến triển, những lựa chọn này dự kiến ​​sẽ hội tụ về chuỗi chính xác với tỷ lệ lỗi 0%.

Một lợi ích của cấu trúc xác suất là mỗi nút không phát sóng quan điểm chuỗi của mình dưới dạng một tin nhắn riêng biệt, giảm thiểu overhead giao tiếp. Do đó, cấu trúc như vậy có thể hoạt động với số nút phi tập trung nhiều hơn, yêu cầu hệ thống thấp hơn. Ngược lại, sự đồng thuận xác định hoạt động thông qua mô hình giao tiếp một tới tất cả. Ở đây, một nút gửi quan điểm chuỗi của mình như là một phiếu bầu đến tất cả các nút khác. Phương pháp này tạo ra mật độ tin nhắn cao hơn, và khi số nút tăng lên, hệ thống cuối cùng có thể đạt đến giới hạn của nó. Tuy nhiên, lợi ích lớn nhất của sự đồng thuận xác định là sự sẵn có của phiếu bầu cụ thể, cho phép bạn biết chính xác nút nào bỏ phiếu cho nhánh nào. Điều này đảm bảo sự kết thúc chuỗi nhanh chóng và xác định, đảm bảo rằng các khối không thể thay đổi thứ tự của họ và làm cho chúng có thể xác minh.

Để cung cấp một cơ chế đồng thuận có thể xác minh trong khi duy trì tính phi tập trung và cấu trúc không cần phép, Ethereum đã tạo ra một sự cân bằng giữa các slot và epoch. Các slot, đại diện cho các khoảng thời gian 12 giây, là các đơn vị cơ bản mà một validator chịu trách nhiệm sản xuất một khối. Mặc dù sự đồng thuận xác suất được sử dụng ở mức slot cho phép chuỗi hoạt động linh hoạt hơn và theo cách phi tập trung, nhưng nó có nhược điểm về việc xác định thứ tự và khả năng xác minh chính xác.

Epochs, bao gồm 32 khe, giới thiệu sự đồng thuận xác định. Tại cấp độ này, người xác minh bỏ phiếu để hoàn tất thứ tự chuỗi, đảm bảo sự chắc chắn và làm cho chuỗi có thể xác minh. Tuy nhiên, trong khi cấu trúc xác định này cung cấp tính xác minh thông qua các phiếu cụ thể tại cấp độ epoch, nó không thể cung cấp tính xác minh đầy đủ trong các epoch chính do cấu trúc xác suất. Để giải quyết khoảng cách này và củng cố cấu trúc xác suất trong các epoch, Ethereum đã phát triển một giải pháp được gọi là Hội đồng Đồng bộ.

Giao thức Khách nhẹ Altair: Ủy ban đồng bộ hóa

Sync Committee là một cơ chế được giới thiệu với bản nâng cấp Altair để vượt qua những hạn chế của sự đồng thuận xác suất của Ethereum và cải thiện tính xác thực của chuỗi đối với các máy khách nhẹ. Hội đồng bao gồm 512 nhà xác thực ngẫu nhiên được chọn để phục vụ trong 256 thời kỳ (~27 giờ). Những nhà xác thực này tạo ra một chữ ký đại diện cho đầu chuỗi, cho phép máy khách nhẹ xác minh tính hợp lệ của chuỗi mà không cần tải dữ liệu chuỗi lịch sử. Hoạt động của Hội đồng Sync có thể được tóm tắt như sau:

1. Hình thành ủy ban:
   512 validator được chọn ngẫu nhiên từ tất cả các validator trong mạng. Việc chọn này được thường xuyên cập nhật để duy trì tính phân tán và ngăn chặn sự phụ thuộc vào một nhóm cụ thể.
2. Signature Generation:
   Các thành viên của ủy ban tạo ra một chữ ký đại diện cho trạng thái mới nhất của chuỗi. Chữ ký này là một chữ ký BLS tập thể được tạo bởi các thành viên và được sử dụng để xác minh tính hợp lệ của chuỗi.
3. Xác minh khách hàng nhẹ:
   Khách hàng nhẹ có thể xác minh tính chính xác của chuỗi bằng cách đơn giản kiểm tra chữ ký từ Ủy ban Sync. Điều này cho phép họ theo dõi chuỗi một cách an toàn mà không cần tải dữ liệu chuỗi trước đó.

Tuy nhiên, Ủy ban Đồng bộ đã bị chỉ trích trong một số lĩnh vực. Đáng chú ý, giao thức thiếu cơ chế cắt giảm trình xác thực cho hành vi độc hại, ngay cả khi các trình xác thực được chọn hành động có chủ ý chống lại giao thức. Do đó, nhiều người coi Ủy ban Đồng bộ hóa là một rủi ro bảo mật và không phân loại đầy đủ nó là Giao thức máy khách nhẹ. Tuy nhiên, tính bảo mật của Ủy ban Đồng bộ hóa đã được chứng minh về mặt toán học và có thể tìm thấy thêm chi tiết trong bài viết này về Sync Committee Slashings.

Sự thiếu một cơ chế cắt giảm trong giao thức không phải là một lựa chọn thiết kế mà là một sự cần thiết phát sinh từ bản chất của sự đồng thuận xác suất. Sự đồng thuận xác suất không cung cấp các bảo đảm tuyệt đối về những gì một người xác nhận quan sát. Ngay cả khi hầu hết các người xác nhận báo cáo rằng một cái nạng cụ thể là nặng hơn, vẫn có thể có các người xác nhận ngoại lệ quan sát một cái nạng khác là nặng hơn. Sự không chắc chắn này làm cho việc chứng minh ý đồ độc hại trở nên khó khăn và do đó không thể trừng phạt hành vi sai trái.

Trong ngữ cảnh này, thay vì gán nhãn Ủy ban Đồng bộ là không an toàn, mô tả nó là một giải pháp không hiệu quả sẽ chính xác hơn. Vấn đề không phải bắt nguồn từ thiết kế cơ khí hoặc hoạt động của Ủy ban Đồng bộ mà là từ bản chất tiềm ẩn của sự đồng thuận xác suất. Vì sự đồng thuận xác suất không thể đảm bảo rõ ràng về những gì các nút quan sát, Ủy ban Đồng bộ là một trong những giải pháp tốt nhất có thể được thiết kế trong một mô hình như vậy. Tuy nhiên, điều này không loại bỏ nhược điểm của sự đồng thuận xác suất trong việc đảm bảo sự kết thúc của chuỗi. Vấn đề không nằm ở cơ chế mà nằm trong cấu trúc sự đồng thuận hiện tại của Ethereum.

Do các hạn chế này, có những nỗ lực liên tục trong hệ sinh thái Ethereum để thiết kế lại cơ chế đồng thuận và triển khai các giải pháp cung cấp sự xác định cuối cùng trong khoảng thời gian ngắn hơn. Các đề xuất như Orbit-SSFvà3SFnhằm tái tạo cấu trúc đồng thuận Ethereum từ đầu, tạo ra một hệ thống hiệu quả hơn để thay thế đồng thuận xác suất. Các phương pháp này không chỉ tìm cách rút ngắn thời gian hoàn chỉnh của chuỗi mà còn mang lại một cấu trúc mạng hiệu quả và có thể xác minh hơn. Cộng đồng Ethereum tiếp tục tích cực phát triển và chuẩn bị những đề xuất này cho việc triển khai trong tương lai.

Snarkification of Consensus

The Verge nhằm mục tiêu tăng cường cơ chế đồng thuận hiện tại và tương lai của Ethereum bằng cách làm cho chúng có thể được xác minh hơn thông qua công nghệ zk-proof, thay vì thay thế chúng hoàn toàn. Tiếp cận này nhằm mục tiêu hiện đại hóa quy trình đồng thuận của Ethereum trong khi vẫn giữ nguyên các nguyên tắc cốt lõi của sự phân quyền và bảo mật. Tối ưu hóa tất cả các quy trình đồng thuận lịch sử và hiện tại của chuỗi với công nghệ zk đóng vai trò quan trọng trong việc đạt được mục tiêu về tính mở rộng và hiệu quả dài hạn của Ethereum. Các hoạt động cơ bản được sử dụng trong lớp đồng thuận của Ethereum rất quan trọng trong quá trình biến đổi công nghệ này. Hãy xem xét kỹ hơn về các hoạt động này và những thách thức mà chúng đối mặt.

• ECADDs:
  • Mục đích: Hoạt động này được sử dụng để tổng hợp các khóa công khai của các nhà xác thực và rất quan trọng để đảm bảo độ chính xác và hiệu suất của chuỗi. Nhờ tính kết hợp của chữ ký BLS, nhiều chữ ký có thể được kết hợp thành một cấu trúc duy nhất. Điều này giảm thiểu tải giao tiếp và làm cho quá trình xác minh trên chuỗi hiệu quả hơn. Đảm bảo đồng bộ hóa hiệu quả hơn giữa các nhóm xác thực lớn làm cho hoạt động này trở nên quan trọng.
  • Thách thức: Như đã đề cập trước đó, các nhà xác minh của Ethereum bỏ phiếu về thứ tự chuỗi trong suốt các kỷ nguyên. Hiện nay, Ethereum là mạng với khoảng 1,1 triệu nhà xác minh. Nếu tất cả các nhà xác minh cố gắng truyền bá phiếu của họ đồng thời, điều này sẽ tạo ra áp lực đáng kể lên mạng. Để tránh điều này, Ethereum cho phép các nhà xác minh bỏ phiếu theo khe cắm trong suốt một kỷ nguyên, nơi chỉ có 1/32 số nhà xác minh bỏ phiếu trên mỗi khe cắm. Mặc dù cơ chế này giảm thiểu chi phí giao tiếp mạng và làm cho sự đồng thuận hiệu quả hơn, nhưng với số lượng nhà xác minh hiện nay, khoảng 34.000 nhà xác minh bỏ phiếu trong mỗi khe cắm. Điều này tương đương khoảng 34.000 hoạt động ECADD cho mỗi khe cắm.
• Pairings:
  • Mục đích: Các hoạt động ghép cặp được sử dụng để xác minh chữ ký BLS, đảm bảo tính hợp lệ của các kỷ nguyên trên chuỗi. Hoạt động này cho phép xác minh lô chữ ký. Tuy nhiên, nó không thân thiện với zk, khiến việc chứng minh bằng công nghệ chứng minh zk trở nên cực kỳ tốn kém. Điều này đặt ra thách thức lớn trong việc tạo quy trình xác minh tích hợp với công nghệ zero-knowledge.
  • Thách thức: Các hoạt động ghép cặp trong Ethereum bị giới hạn tối đa 128 chứng nhận (chữ ký tổng hợp) mỗi khe, dẫn đến ít hoạt động ghép cặp hơn so với ECADDs. Tuy nhiên, sự thiếu thiện chí zk trong các hoạt động này đặt ra một thách thức đáng kể. Chứng minh một hoạt động ghép cặp với zk-proofs tốn nhiều hơn hàng nghìn lần so với chứng minh một hoạt động ECADD [2]. Điều này khiến việc thích nghi các hoạt động ghép cặp cho các công nghệ không biết được là một trong những rào cản lớn nhất trong quá trình xác minh sự nhất quán của Ethereum.
• Băm SHA256:
  • Mục đích: Các hàm băm SHA256 được sử dụng để đọc và cập nhật trạng thái của chuỗi, đảm bảo tính toàn vẹn của dữ liệu của chuỗi. Tuy nhiên, việc thiếu tính thân thiện với zk dẫn đến hiệu suất không hiệu quả trong quá trình xác minh dựa trên zk-proof, tạo ra một rào cản lớn đối với mục tiêu xác minh của Ethereum trong tương lai.
  • Thách thức: Hàm băm SHA256 thường được sử dụng để đọc và cập nhật trạng thái của chuỗi. Tuy nhiên, tính không thân thiện với zk của chúng xung đột với mục tiêu xác minh dựa trên chứng minh zk của Ethereum. Ví dụ, giữa hai kỷ nguyên, mỗi nhà xác minh chạy STF của Lớp Consensus của Ethereum để cập nhật trạng thái với phần thưởng và phạt dựa trên hiệu suất của nhà xác minh trong kỷ nguyên. Quá trình này đặt nặng vào hàm băm SHA256, làm tăng đáng kể chi phí trong các hệ thống dựa trên chứng minh zk. Điều này tạo ra một rào cản đáng kể trong việc điều chỉnh cơ chế đồng thuận Ethereum với công nghệ zk.

Các hoạt động ECADD, Pairing và SHA256 được sử dụng trong lớp sự đồng thuận hiện tại đóng một vai trò quan trọng trong mục tiêu xác thực của Ethereum. Tuy nhiên, sự thiếu thân thiện với zk của chúng đặt ra những thách thức đáng kể trên con đường đạt được những mục tiêu này. Các hoạt động ECADD tạo ra một gánh nặng đắt đỏ do số lượng phiếu bầu của người xác minh cao, trong khi các hoạt động Pairing, mặc dù ít hơn về số lượng, lại đắt gấp hàng nghìn lần khi chứng minh với zk-proofs. Ngoài ra, sự không thân thiện với zk của các hàm băm SHA256 khiến cho việc chứng minh chuyển tiếp trạng thái của chuỗi phản chiếu vô cùng thách thức. Những vấn đề này làm nổi bật nhu cầu về một sự chuyển đổi toàn diện để điều chỉnh cơ sở hạ tầng hiện có của Ethereum với các công nghệ không bảo mật.

Giải pháp “Beam Chain”: Tưởng tượng lại tầng Consensus của Ethereum

Vào ngày 12 tháng 11 năm 2024, trong buổi thuyết trình của mình tại Devcon, Justin Drake giới thiệu một đề xuất mang tên “Beam Chain” nhằm mục đích biến đổi và cải tổ toàn diện lớp Consensus của Ethereum. Beacon Chain đã nằm ở trung tâm của mạng Ethereum trong gần năm năm qua. Tuy nhiên, trong thời gian này, không có thay đổi cấu trúc lớn nào được thực hiện đối với Beacon Chain. Ngược lại, sự tiến bộ về công nghệ đã tiến triển nhanh chóng, vượt xa tính tĩnh của Beacon Chain.

Trong bài thuyết trình của mình, Justin Drake nhấn mạnh rằng Ethereum đã rút ra được những bài học đáng kể trong suốt năm năm qua ở những lĩnh vực quan trọng như hiểu biết về MEV, những đột phá trong công nghệ SNARK và nhận thức phản hồi về những sai lầm công nghệ. Những thiết kế dựa trên những kiến thức mới này được phân loại thành ba trụ cột chính: Sản xuất khối, Stake và Mật mã học. Hình sau tóm tắt những thiết kế này và lộ trình đề xuất:

• Các hộp màu xanh và xám đại diện cho sự phát triển tăng dần mà có thể được triển khai từng bước một mỗi năm. Những loại cải tiến này, giống như những bản nâng cấp trước đó, có thể được tích hợp từng bước một mà không làm gián đoạn kiến trúc hiện tại của Ethereum.
• Các hộp màu đỏ, ngược lại, tượng trưng cho sự tương hợp cao, quy mô lớn và các thay đổi cơ bản mà phải được triển khai cùng nhau. Theo Drake, những thay đổi này nhằm mục tiêu nâng cao khả năng và khả năng xác minh của Ethereum trong một bước tiến lớn.

Trong phần này, chúng tôi đã xem xét chi tiết các bước Consensus, State và Execution của The Verge, và một trong những vấn đề nổi bật nhất được đưa ra trong quá trình này là việc sử dụng hàm băm SHA256 trong Beacon Chain của Ethereum. Trong khi SHA256 đóng vai trò trung tâm trong đảm bảo an ninh của mạng và xử lý giao dịch, việc thiếu tính thân thiện với zk đặt ra một rào cản đáng kể trong việc đạt được mục tiêu xác thực của Ethereum. Chi phí tính toán cao và không tương thích với công nghệ zk khiến nó trở thành một vấn đề quan trọng phải được giải quyết trong các phát triển tương lai của Ethereum.

Lộ trình của Justin Drake, được trình bày trong buổi nói chuyện tại Devcon, dự định thay thế SHA256 trong Beacon Chain bằng các hàm băm thân thiện với zk như Poseidon. Đề xuất này nhằm mục tiêu cập nhật lớp đồng thuận của Ethereum, làm cho nó có thể xác minh, hiệu quả hơn và phù hợp hơn với các công nghệ chứng minh zk.

Trong ngữ cảnh này, chúng ta thấy rằng Ethereum không chỉ đối mặt với thách thức từ các hàm băm không thân thiện với zk mà còn cần phải đánh giá lại các chữ ký số được sử dụng trong lớp đồng thuận của mình để đảm bảo an ninh dài hạn. Với sự tiến bộ của máy tính lượng tử, các thuật toán chữ ký số như ECDSA hiện đang được sử dụng có thể đối mặt với các mối đe dọa đáng kể. Như đã ghi chú trong hướng dẫn được xuất bản bởi NIST, các biến thể của ECDSA với mức độ an ninh 112 bit sẽ bị loại bỏ vào năm 2030 và hoàn toàn bị cấm vào năm 2035. Điều này đòi hỏi một sự chuyển đổi cho Ethereum và các mạng tương tự hướng tới các phương án thay thế mạnh mẽ hơn như các chữ ký an toàn với lượng tử trong tương lai.

Tại thời điểm này, chữ ký dựa trên băm nổi lên như là các giải pháp chống lại quantum có thể đóng một vai trò quan trọng trong việc hỗ trợ cho mục tiêu bảo mật và xác thực mạng. Giải quyết nhu cầu này cũng loại bỏ rào cản thứ hai để làm cho Beacon Chain có thể được xác thực: Chữ ký BLS. Một trong những bước quan trọng nhất mà Ethereum có thể thực hiện để đảm bảo an toàn đối với quantum là áp dụng các giải pháp post-quantum như chữ ký dựa trên băm và hash-based SNARKs.

Như Justin Drake nhấn mạnh trong bài thuyết trình của ông ta tại Devcon, các hàm băm bản chất có khả năng chống lại máy tính lượng tử do sự phụ thuộc của chúng vào khả năng chống lại hình ảnh trước, làm cho chúng trở thành một trong những khối xây dựng cơ bản của mật mã hiện đại. Tính chất này đảm bảo rằng ngay cả máy tính lượng tử cũng không thể đảo ngược hiệu quả đầu vào ban đầu từ một hàm băm đã cho, bảo vệ tính bảo mật của chúng. Hệ thống chữ ký dựa trên hàm băm cho phép các nhà xác minh và chứng thực tạo ra các chữ ký hoàn toàn dựa trên các hàm băm, đảm bảo tính bảo mật sau lượng tử và đồng thời cung cấp một mức độ xác minh cao hơn trên mạng - đặc biệt nếu sử dụng một hàm băm thân thiện với SNARK. Phương pháp này không chỉ nâng cao tính bảo mật của mạng mà còn làm cho cơ sở hạ tầng bảo mật dài hạn của Ethereum mạnh mẽ hơn và chuẩn bị cho tương lai.

Hệ thống này dựa trên việc kết hợp chữ ký dựa trên hash và các chứng cứ dựa trên hash (chứng cứ STARK giống như) để tạo ra các hệ thống chữ ký có thể tổng hợp. Chữ ký có thể tổng hợp nén hàng nghìn chữ ký thành một cấu trúc duy nhất, giảm nó thành chỉ vài trăm kilobyte chứng cứ. Quá trình nén này giảm đáng kể tải dữ liệu trên mạng trong khi đồng thời tăng tốc quá trình xác minh. Ví dụ, hàng nghìn chữ ký của người xác minh được tạo ra cho một khe cắm duy nhất trên Ethereum có thể được biểu diễn bằng một chữ ký tổng hợp duy nhất, tiết kiệm cả không gian lưu trữ và sức mạnh tính toán.

Tuy nhiên, đặc điểm đáng chú ý nhất của hệ thống này là sự tổng hợp vô hạn. Nghĩa là, một nhóm chữ ký có thể được kết hợp tiếp theo dưới một nhóm khác, và quá trình này có thể tiếp tục trên chuỗi. Với cơ chế này và xem xét các tiến bộ công nghệ trong tương lai, có thể nói rằng điều này mở ra cánh cửa cho những khả năng hiện tại không thể đạt được với BLS.

Suy nghĩ cuối cùng và kết luận

Con đường dẫn đến khả năng xác minh của Ethereum đại diện cho một sự thay đổi cơ bản trong công nghệ blockchain. Sáng kiến Verge giải quyết sự thiếu hiệu quả cốt lõi thông qua Verkle Trees để xác minh trạng thái và bằng chứng STARK cho quá trình chuyển đổi có thể mở rộng.

Một trong những đề xuất tham vọng nhất là Beam Chain, một thiết kế lại toàn diện lớp đồng thuận của Ethereum. Bằng cách giải quyết những hạn chế của Beacon Chain và kết hợp các lựa chọn thay thế thân thiện với zk, cách tiếp cận này nhằm mục đích nâng cao khả năng mở rộng của Ethereum trong khi vẫn giữ nguyên các nguyên tắc cốt lõi của nó về phân cấp và khả năng tiếp cận. Tuy nhiên, quá trình chuyển đổi cũng làm nổi bật những thách thức Ethereum phải đối mặt trong việc cân bằng nhu cầu tính toán với mục tiêu duy trì một mạng lưới toàn diện, không được phép.

Với việc NIST dự định loại bỏ mật mã đường cong elip hiện tại vào năm 2035, Ethereum phải áp dụng các giải pháp chống lại lượng tử như chữ ký dựa trên băm và Poseidon. Những giải pháp này đều có nhược điểm hiệu suất riêng của chúng.

Việc sử dụng STARK trong lộ trình của Ethereum nhấn mạnh hơn nữa khả năng mở rộng và khả năng xác minh. Mặc dù họ vượt trội trong việc cung cấp các bằng chứng minh bạch và chống lượng tử, sự tích hợp của họ đưa ra những thách thức liên quan đến chi phí tính toán bên lề tục ngữ và sự thiếu hiệu quả của dữ liệu nhỏ. Những rào cản này phải được giải quyết để nhận ra đầy đủ tầm nhìn của Ethereum về tình trạng không quốc tịch và xác minh khối hiệu quả, đảm bảo mạng vẫn mạnh mẽ khi đối mặt với nhu cầu ngày càng tăng.

Mặc dù có những tiến bộ này, vẫn còn những thách thức quan trọng. Ethereum phải vượt qua các vấn đề về tính thân thiện với zk, tính mở rộng của đồng thuận và những phức tạp khi tích hợp mật mã chống lại lượng tử. Hơn nữa, tính tương thích ngược của cơ sở hạ tầng hiện có đặt ra những trở ngại thực tế đòi hỏi các giải pháp kỹ thuật cẩn thận để ngăn chặn sự gián đoạn đối với các nhà phát triển và người dùng.

Điều làm Ethereum nổi bật không chỉ là các đổi mới kỹ thuật mà còn là cách tiếp cận theo từng bước để giải quyết những vấn đề khó nhất trong blockchain. Con đường phía trước - dù thông qua các công nghệ như Beam Chain, Verkle Trees hoặc STARK proofs - phụ thuộc vào sự cộng tác của các nhà phát triển, nhà nghiên cứu và cộng đồng rộng hơn. Những tiến bộ này không phải là về việc đạt được sự hoàn thiện ngay lập tức mà là về việc tạo nên một nền tảng cho một internet minh bạch, phi tập trung và có thể xác minh được.

Sự tiến hóa của Ethereum nhấn mạnh vai trò quan trọng của nó trong việc định hình kỷ nguyên Web3. Bằng cách giải quyết các thách thức hiện tại bằng các giải pháp thực tế, Ethereum tiến gần hơn đến một tương lai khi tính xác minh, khả năng chống lại lượng tử và khả năng mở rộng trở thành tiêu chuẩn, chứ không phải là ngoại lệ.

Disclaimer:

1. Bài viết này được tái bản từ [[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[Nghiên cứu năm 2077](https://research.2077.xyz/)\]. Tất cả bản quyền thuộc về tác giả gốc [Koray Akpinarr]. Nếu có ý kiến phản đối về việc tái bản này, vui lòng liên hệ với Gate Learnđội ngũ, và họ sẽ xử lý nhanh chóng.
2. Xin lưu ý trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không hề đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã được dịch là không được phép.