Năm 2024, nhiều sự kiện quan trọng đã xảy ra xung quanh Ethereum. Đầu năm, Ethereum giới thiệu blobs thông qua bản nâng cấp Dencun. Cập nhật này đã giảm đáng kể chi phí giao dịch cho các rollup hiện có, tạo nền tảng cho sự mở rộng nhanh chóng của hệ sinh thái rollup.
(Giảm phí trong OP Chains sau nâng cấp Dencun | Nguồn:Optimism X)
Tuy nhiên, khi các dapp trong hệ sinh thái chuyển sang các mạng rollup và mạng Layer 1 (L1) thay thế có khả năng mở rộng cao, hoạt động của người dùng trên Ethereum bắt đầu giảm. Ngoài ra, khi các rollup ngưng nộp phí cao cho Ethereum, những lo ngại bắt đầu nảy sinh trong cộng đồng.
Ngoài ra, năm 2024 cũng là năm mà các nền tảng tập trung vào khả năng mở rộng L1 như Solana và Sui đã thể hiện sức mạnh đáng kể. Số lượng TPS (giao dịch trên giây) khổng lồ được tạo ra bởi những mạng này khiến hoạt động trên rollups dường như nhỏ bé.
Trong ngữ cảnh này, đã xuất hiện những lời chỉ trích, như “Lộ trình tập trung vào Ethereum của Ethereum có nhược điểm” hoặc “Sự phát triển của Ethereum quá chậm để thành công.” Ethereum thực sự đang trên đúng con đường? Ethereum sẽ trông như thế nào vào năm 2025 hoặc thậm chí là 2030?
Chuỗi bài viết này sẽ khám phá các phần của lộ trình của Ethereum dưới hai chủ đề chính, phân tích tương lai của nó dựa trên các chi tiết kỹ thuật. Chủ đề đầu tiên là Chuỗi Beam.
Nếu ai đó muốn chọn chủ đề được nói nhiều nhất trong cộng đồng Ethereum năm nay, có lẽ đó sẽ là thông báo về Beam Chain của nhà nghiên cứu Ethereum Justin Drake tại Devcon. Thông báo này đã thu hút rất nhiều sự quan tâm và, tương ứng, nhiều tiếng ồn. Hãy phân tích ý nghĩa của đề xuất này.
Ý tưởng cốt lõi của đề xuất Beam Chain là thiết kế lại hoàn toàn tầng phiên quyết Ethereum. Justin Drake đã trình bày ba lý do sau đây vì sao tầng phiên quyết hiện tại, Beacon Chain, cần được thiết kế lại:
Hiện tại, lộ trình lớp đồng thuận Ethereum bao gồm các yếu tố sau đây:
Trong số đó, bốn khu vực được đánh dấu đậm đại diện cho những thay đổi cơ bản vượt xa việc chỉ sửa đổi Beacon Chain. Ví dụ, snarkification của chuỗi đề cập đến việc chuyển đổi xử lý trạng thái của lớp đồng thuận thành công nghệ ZK, đòi hỏi những thay đổi cơ bản bắt đầu từ các hàm băm cho đến các phương pháp của merkleizing / serializing state.
Ngoài ra, các khe cắm nhanh hơn và sự hoàn thiện nhanh hơn là những thiết kế mới được đề xuất để đạt được cải tiến về hiệu suất trong khi vẫn duy trì tính bảo mật—một yếu tố không được ưu tiên trong các thiết kế ban đầu. Việc triển khai này đòi hỏi những sự thay đổi to lớn tại tầng đồng thuận.
Beam Chain đề xuất thực hiện những thay đổi này thông qua một hard fork duy nhất. Tóm lại:
Tiếp theo, chúng ta hãy khám phá cách thực hiện từng phần này và những tác động kỹ thuật mà chúng mang lại.
Hiện tại, thời gian khe của Ethereum là 12 giây, và mất 2-3 thời kỳ (khoảng 15 phút) để một khối được kết nối với khe đạt được sự hoàn thiện cuối cùng. Cải thiện thời gian này sẽ tác động tích cực đến người dùng, ứng dụng và rollups xây dựng trên Ethereum.
Chủ đề này, được biết đến trong cộng đồng nghiên cứu Ethereum với tên gọi là SSF (Single Slot Finality), nhằm mục tiêu rút ngắn thời gian để các khối Ethereum đạt đến tính cuối cùng từ khoảng 15 phút xuống còn 12 giây, cung cấp cho người dùng việc xác nhận nhanh hơn. Để hiểu về tính cuối cùng dựa trên một khe, chúng ta cần hiểu về thuật toán đồng thuận hiện tại của Ethereum, Gasper.
Một nguyên tắc thiết kế chính của Gasper là đảm bảo rằng một khối được đề xuất trong một khe đạt được một mức độ an ninh kinh tế nhất định sau một khoảng thời gian nhất định trong khi giảm thiểu tải truyền thông trên mỗi người xác minh. Để đạt được điều này, Ethereum chia toàn bộ bộ xác minh thành các ủy ban phân phối trên 32 khe. Mỗi khe có thể chứa đến 64 ủy ban, và mục tiêu là hình thành mỗi ủy ban từ 128 người xác minh (mặc dù số này có thể tăng nếu tổng số người xác minh hoạt động vượt quá điều này).
Các validator trong mỗi ủy ban độc lập xác minh khối và bỏ phiếu trên đó bằng chữ ký BLS. Cơ chế chữ ký BLS cho phép nhiều chữ ký được tổng hợp thành một, có nghĩa là một nút được chỉ định trong ủy ban thu thập những chữ ký này và biên soạn chúng thành một gói dữ liệu nhỏ gọn duy nhất. Bằng cách phát sóng chữ ký tổng hợp này, người đề xuất khối tiếp theo có thể xác nhận với dữ liệu tối thiểu rằng khối đã được xác minh đúng cách.
(Tích hợp chữ ký BLS giữa các nhà xác thực trên Ethereum | Nguồn: eth2book)
Tóm lại, Gasper của Ethereum đạt được cả sự mở rộng khả năng và an ninh kinh tế thông qua các cơ chế sau:
Tuy nhiên, một vấn đề nảy sinh là Gasper hoạt động trên cơ sở kỷ nguyên, và ‘kết nối’ giữa các kỷ nguyên phải được xác minh trước khi một khe có thể đạt được tính chất cuối cùng. Trong Gasper, tối thiểu hai kỷ nguyên (64 khe) phải trôi qua trước khi đạt được tính chất cuối cùng tương đương với an ninh kinh tế hoàn chỉnh của Ethereum.
Điều này dẫn đến biểu đồ đại diện sau:
(Economic Finality at Gasper | Source:Orbit SSF)
Điều này đưa ra nhiều thách thức khác nhau và làm giảm UX. Ví dụ:
Ví dụ, vào tháng 3 năm 2024, Polygon zkEVM đã gặp sự cố gián đoạn chuỗi kéo dài hơn hai ngày do xử lý không đúng của Ethereum reorg.
Giảm thời gian để hoàn thiện không phải là điều không thể, như đã được chứng minh bởi các thuật toán đồng thuận như Tendermint, đã được áp dụng trong một số giao thức. Tuy nhiên, thách thức khi áp dụng cơ chế Tendermint nằm ở việc giao tiếp P2P thường xuyên giữa các nút, gây ra hạn chế về khả năng mở rộng.
Trong Tendermint, nếu số lượng node là N, độ phức tạp thông điệp của nó là O(N^3). Điều này có nghĩa là khi số lượng node tăng lên, tần suất giao tiếp giữa chúng tăng một cách mũ, hạn chế tính mở rộng. Do đó, các giao thức như Ethereum, với nhiều người xác minh, không thể trực tiếp áp dụng Tendermint như hiện tại.
Cần phải thực hiện công việc bổ sung để giải quyết những vấn đề này để áp dụng sự đồng thuận kiểu Tendermint cho Ethereum.
Orbit SSF nhằm sửa đổi cơ chế ủy ban Gasper để giảm thời gian cho sự cuối cùng của khe hở trong khi duy trì an ninh kinh tế cao.
Đề xuất là giảm kích thước epoch từ 32 khe cắm xuống một khe cắm duy nhất (~12 giây). Tuy nhiên, như đã đề cập trước đó, điều này sẽ tăng tài nguyên sử dụng cho việc giao tiếp của người xác thực, ảnh hưởng tiêu cực đến sự phân quyền của Ethereum.
Để giải quyết vấn đề này, Orbit SSF đề xuất những ý tưởng sau:
Tăng mức tối đa số tiền cược cho mỗi Ethereum validator có thể đạt được cùng mức độ bảo mật kinh tế với ít hơn số lượng validators.
Thay vì việc có nhiều đoạn thảo cho một khe, Orbit SSF đề xuất giới thiệu một “sàn quyền siêu” duy nhất. Người xác minh với số lượng cục lớn hơn sẽ gần như luôn luôn được bao gồm một cách tệ nhân trong đoạn thảo, đảm bảo rằng cùng một mục độ an ninh kinh tế được duy trì ngay cả khi có ít đoạn thảo hơn.
Bản nâng cấp Ethereum tiếp theo, Pectra, bao gồm EIP-7251, đề xuất tăng mức tối đa cho số tiền đặt cược (MaxEB) của các nhà xác minh từ 32 ETH lên 2048 ETH. Mặc dù đề xuất này hấp dẫn đối với các nhà vận hành cơ sở hạ tầng Ethereum, nó cũng là một điều kiện tiên quyết cho Orbit SSF.
Tuy nhiên, nếu những người xác minh có số lượng cọc lớn thường được bao gồm trong các ủy ban, những người xác minh đơn lẻ nhỏ hơn có thể gặp phải giảm phần thưởng, tiềm năng gây hại đến sự phân quyền của Ethereum. Để ngăn chặn điều này, Orbit SSF điều chỉnh phần thưởng để tỷ suất tăng tuyến tính theo số lượng cọc trong khi đảm bảo rằng những người xác minh lớn hơn được bao gồm trong các ủy ban thường xuyên hơn.
(Phần thưởng và Xác suất được đưa vào ủy ban trong Orbit SSF | Nguồn:Orbit SSF)
Ngoài ra, Orbit SSF chuyển đổi sang “sự quyết định dựa trên ủy ban.” Trong Gasper, các ủy ban chỉ có thể đóng góp vào sự quyết định sau khi đã qua hai hoặc nhiều thời kỳ, nhưng Orbit SSF cho phép mỗi ủy ban được gán khe có thể đóng góp vào sự quyết định trong thời gian thực. Nó nhằm mục tiêu làm cho các ủy ban trở thành những người đóng góp tích cực hơn vào sự quyết định và đạt được tính mở rộng nhanh hơn.
(Finality in Orbit SSF sử dụng Cap-and-slow-rotate | Nguồn:Orbit SSF)
Chìa khóa ở đây nằm ở việc tổ chức thành viên hội đồng. Orbit SSF đề xuất một cơ chế “quay chậm” trong đó các thợ đạo đại biểu có cổ phần lớn gần như cố định trong các hội đồng trong khi các thợ đạo nhỏ được xoay vào và ra khỏi. Điều này cho phép giá trị của F, đại diện cho ngưỡng an ninh kinh tế, được đặt rất cao trong khi duy trì giao tiếp tối thiểu giữa các thợ đạo và đảm bảo thời gian cuối cùng vẫn giữ ở mức thấp.
Ví dụ, đặt n = 3 và một F đáng kể lớn sẽ cho phép Ethereum đạt được tính cuối cùng trong khoảng ba khe, từ đó thực hiện được tầm nhìn 3-slot FFG của Justin Drake.
Tuy nhiên, việc nâng F lên mức của toàn bộ tập hợp xác minh của Ethereum không dễ dàng. Điều này có thể giảm chi phí thực hiện cuộc tấn công 51% trên Ethereum. Do đó, thách thức chính đối với Orbit SSF trong tương lai là xác định cách tăng F một cách kỹ thuật để đảm bảo rằng sự an toàn của Ethereum vẫn mạnh mẽ mà không cần phải hy sinh quá nhiều sự phi tập trung.
Thời gian khe cắm ngắn hơn (khe cắm 4 giây)Ngay cả khi SSF (hoặc độ tin cậy 3 khe cắm) được đạt được, người dùng Ethereum vẫn sẽ gặp thời gian xác nhận giao dịch tối thiểu là 12 giây. Điều này dẫn đến hai hạn chế chính đối với người dùng:
Ngoài ra, thời gian khối 12 giây đặc biệt bất lợi cho rollups, đặc biệt là rollups dựa trên. Ví dụ, Taiko triển khai một rollup dựa trên bằng cách đăng mỗi khối L2 lên L1. Kết quả, thời gian khối của Taiko có thể tăng lên tối thiểu 12 giây và đôi khi vượt quá 24 giây.
Đã có hai giải pháp được đề xuất để giải quyết vấn đề này:
a. Giảm thời gian khối Ethereum xuống 4 hoặc 8 giây
b. Sử dụng trước khi xác nhận
Việc giảm thời gian khối Ethereum đang là chủ đề được thảo luận tích cực. Đã được hình thành dưới dạng EIP-7782, đề xuất giảm thời gian khe từ 12 giây xuống 8 giây, qua đó tăng khả năng mở rộng của Ethereum lên 33%. Tuy nhiên, một thời gian khe 8 giây có thể không phải là tối ưu cho trải nghiệm người dùng hoặc dựa trên rollups. Việc đạt được một thời gian khe ngắn hơn dường như hấp dẫn hơn.
Tuy nói vậy, thời gian khối ngắn có thể dẫn đến sự tập trung tăng của bộ xác thực. Do hạn chế về vật lý, các bộ xác thực cách xa địa lý gặp phải thời gian truyền thông lâu hơn, và thời gian khe 4 giây có thể làm cho việc truyền thông trở nên không khả thi trong một số tình huống.
Thống kê thời gian truyền khối của mainnet Ethereum cung cấp cái nhìn về khả năng thực hiện thời gian khối 4 giây. Biểu đồ dưới đây cho thấy phân phối thời gian truyền khối.
(CDF thời gian đến tin nhắn | Nguồn:Độ trễ truyền tin Gossipsub)
Khoảng 98% khối được truyền tải trong vòng 4 giây, trong khi khoảng 2% mất thời gian lâu hơn. Dựa trên dữ liệu này, thời gian khối 4 giây có thể khả thi. Tuy nhiên, thời gian khối không chỉ bao gồm giao tiếp mà còn bao gồm thực thi và bỏ phiếu. Xem xét những yếu tố này, chỉ có khoảng 2 giây trong thời gian khối 4 giây sẽ có sẵn để giao tiếp. Trong điều kiện này, việc đạt được thời gian khối 4 giây là thách thức.
Để giải quyết vấn đề này, kích thước dữ liệu truyền phải được giảm xuống, hiệu suất của các thành phần P2P trong các máy khách phải được tối đa hóa, hoặc giao tiếp vật lý phải trở nên hiệu quả hơn.
Trong thời gian chờ đợi, việc xác nhận trước có thể cải thiện trải nghiệm người dùng. Xác nhận trước cho phép các thực thể sản xuất khối hứa với người dùng, “Giao dịch của bạn sẽ được bao gồm trong khối tiếp theo,” mang lại kết quả cho người dùng nhanh hơn thời gian khe.
Lợi ích của việc xác nhận trước là các nhà xác nhận L1 có thể sử dụng nó mà không cần yêu cầu một sự chia tách hoặc sửa đổi khách hàng. Ví dụ, Commit-Boost là phần mềm cho phép các nhà xác nhận Ethereum tạo và truyền đi các xác nhận trước một cách an toàn.
Commit-Boost, giống như MEV-Boost, là một bên phụ tùy chọn cho các validators, cho phép họ sinh ra và lan truyền “commitments” một cách an toàn. Tùy thuộc vào trường hợp sử dụng, những commitments này có thể có nhiều hình thức khác nhau:
Sử dụng kiến trúc tiền xác nhận loại ba, thời gian chờ đợi được cảm nhận của người dùng có thể giảm đáng kể ngay cả khi có thời gian khối dài hơn. Khi một người xác nhận nhận được giao dịch của người dùng, họ có thể thực hiện và trả kết quả cho người dùng. Vì kết quả này dựa trên cam kết của người xác nhận và không phải việc tạo khối, người dùng có thể nhận được nó trong vài mili giây.
Tuy nhiên, hiệu quả của Commit-Boost phụ thuộc vào việc các nhà xác minh sử dụng nó. Nếu chỉ có một số ít nhà xác minh sử dụng nó, tác động lên trải nghiệm người dùng sẽ rất nhỏ. Tuy nhiên, Commit-Boost đã nhận được sự ủng hộ mạnh mẽ từ cộng đồng Ethereum và có tiềm năng trở thành một middleware phổ biến như MEV-Boost. Nó đã nhận được sự ủng hộ từ các nhà điều hành xác minh nổi tiếng như Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41 và Figment. Ngoài ra, nó đã nhận được các hỗ trợ từ EF, Lido và Eigenlayer và được sự hỗ trợ mạnh mẽ từ nhà xây dựng khối Titan.
Tuy nhiên, như đã đề cập trước đó, việc xác nhận trước có khả năng được sử dụng như một off-chain sidecar như MEV-Boost hơn là được tích hợp trực tiếp vào giao thức.
Vai trò của Beam Chain trong việc tăng tốc khe cắm
Như đã thảo luận trong bài thuyết trình của Justin Drake, mục tiêu của Beam Chain là giảm thời gian khối. Do đó, nghiên cứu và triển khai có thể tập trung vào việc giảm thời gian khe cắm xuống 4 giây mà không đánh đổi tính phân quyền. Điều này có thể được giải quyết bằng cách tối ưu hóa toàn bộ Ethereum, sẽ được giải thích trong phần cuối của bài viết này.
Trong bài thuyết trình của mình, Justin đã nói rằng mục tiêu của Beam Chain là sử dụng công nghệ ZK để snarkify consensus client. Điều này có nghĩa là gì, làm thế nào để đạt được và tại sao lại cần thiết?
Hiện tại, Beacon Chain của Ethereum đạt được sự nhất quán bằng cách yêu cầu các nhà xác minh ‘thực hiện lại’ mỗi khối để xác minh rằng rễ trạng thái kết quả là chính xác. Quá trình thực hiện lại này gây ra hiệu suất kém và làm như một rào cản cho việc giảm yêu cầu phần cứng cho nhà xác minh.
Beam Chain nhằm thay thế quá trình thực hiện lại này bằng quá trình “xác minh” sử dụng công nghệ ZK. Điều này sẽ giảm đáng kể yêu cầu về phần cứng cho các bên xác minh và cho phép bất kỳ ai cũng có thể chạy một nút Ethereum từ bất cứ đâu. Để đạt được điều này, Beam Chain và Ethereum sẽ sử dụng ZK SNARKs.
ZK SNARKs có hai thuộc tính sau:
Ý tưởng là áp dụng ZK vào các tính toán và dữ liệu cần thiết cho sự đồng thuận trong Ethereum, tạo ra chứng minh rằng logic đã được tuân theo. Điều này có nghĩa là các người xác minh có thể đạt được sự đồng thuận bằng cách xác minh chứng minh ZK thay vì thực hiện lại toàn bộ khối và lưu trữ trạng thái cập nhật. Việc xác minh chứng minh ZK hiệu quả hơn rất nhiều về kích thước dữ liệu và tính mở rộng so với việc thực hiện lại.
Kết quả là, yêu cầu về phần cứng cho các máy chủ Ethereum có thể được giảm đáng kể. Ví dụ, Vitalik đã cho biết trong bài viết trên The Verge rằng mục tiêu là cho phép các máy chủ hoạt động ngay cả trên môi trường có tài nguyên hạn chế như đồng hồ thông minh.
Bước đầu tiên là biến chuyển chức năng trạng thái thành dạng snark. Chức năng chuyển trạng thái thường có dạng như sau:
f(S,B)=S’
Ở đây:
Tất cả các chuỗi khối đều dựa trên các hàm chuyển trạng thái xác định, và Ethereum cũng không nằm ngoài quy tắc đó. Ethereum có các hàm chuyển trạng thái khác nhau cho các lớp consensus và thực thi của mình. Việc Snarkifying cả hai này sẽ khiến việc xác minh toàn bộ hệ thống Ethereum trở nên có thể thông qua ZK, từ đó cho phép các bộ xác minh siêu nhẹ hoàn toàn.
Trong Beam Chain, mục tiêu là làm cho chức năng chuyển đổi trạng thái của lớp đồng thuận trở nên snarkify. Hiện tại, chức năng chuyển đổi trạng thái trong lớp đồng thuận của Ethereum được thực hiện trong mỗi khe và thực hiện các hành động sau:
Hàm này được thực thi mỗi khi một validator nhận được một khối từ một validator khác. Nếu hàm này được snarkified, các validator sẽ không còn cần thực thi hàm chuyển trạng thái trực tiếp nữa. Thay vào đó, họ có thể xác minh một bằng chứng cho thấy rằng hàm đã được thực thi đúng.
Trong trường hợp này, ai tạo ra chứng minh ZK? Thông thường, người đề xuất của khối cũng có trách nhiệm tạo ra chứng minh ZK. Tuy nhiên, điều quan trọng cần lưu ý là không phải tất cả các nhà xác minh đều có thể tạo ra chứng minh ZK.
Beam Chain nhằm đạt hiệu năng mà một ZK proof có thể được tạo ra trong vòng 3 giây trên một laptop tiêu chuẩn. Tuy nhiên, ngay cả khi mục tiêu này được đạt, các validator chạy trên các thiết bị như smartwatch hoặc điện thoại thông minh có thể không có đủ tài nguyên để tạo ra ZK proof.
Ở đây, mạng có thể dựa vào lòng vị tha. Chỉ cần một bằng chứng ZK cho quá trình chuyển đổi trạng thái của lớp đồng thuận được tạo ra cho mỗi khối, và không nhất thiết phải do người đề xuất khối tạo ra. Nói cách khác, miễn là ít nhất một thực thể trong mạng tạo ra một bằng chứng ZK cho mỗi khối, nó có thể đảm bảo rằng các khối của Beam Chain được tạo ra đúng.
Chính sự thay đổi này có thể không cải thiện đáng kể hiệu suất của bộ xác thực. Hàm chuyển trạng thái của lớp đồng thuận liên quan đến các hoạt động nhẹ hơn so với hàm chuyển trạng thái của lớp thực thi. Tuy nhiên, điểm nghẽn chính không nằm ở tài nguyên cần thiết để thực thi hàm chuyển trạng thái mà nằm ở băng thông mạng. Bộ xác thực gặp khó khăn trong việc đạt được sự đồng thuận trong khoảng thời gian đã được cấp phát khi kích thước dữ liệu (khối) mà họ trao đổi tăng lên. Đây là một trong những lý do mà Ethereum đã duy trì giới hạn gas là 30 triệu trong ba năm qua.
Nếu thay đổi này được thực hiện song song với việc sử dụng SNARK cho lớp thực thi, các validator chỉ cần trao đổi một lượng dữ liệu nhỏ hơn nhiều so với toàn bộ khối. Điều này là do chứng thực SNARK có kích thước nhỏ hơn rất nhiều so với dữ liệu gốc. Các validator Ethereum được hoàn toàn chứng thực SNARK sẽ trao đổi ít dữ liệu hơn, giảm yêu cầu mạng so với hệ thống hiện tại.
Tóm lại, sau đây là những lợi ích của việc snarkification đầy đủ của Ethereum cho các máy chủ xác thực.
Kết quả là hệ sinh thái Ethereum có thể thay đổi một cách đáng kể. Ví dụ:
Điều này sẽ làm cho việc tham gia của validator dễ dàng hơn và phi tập trung hơn.
Việc snarkify hóa hàm chuyển trạng thái liệu có đủ để làm lớp đồng thuận của Beam Chain không?
Có một lĩnh vực khác mà Beam Chain nhắm đến: quá trình tạo chữ ký. Lớp đồng thuận Ethereum hiện tại sử dụng chữ ký của những người xác thực làm dữ liệu xác nhận để hoàn thiện các khối và xác định chuỗi chính xác trong trường hợp có sự phân nhánh.
Hiện tại, Ethereum sử dụng chữ ký BLS cho mục đích này, như đã được giải thích trước đây, có tính chất tổng hợp, cho phép nhiều chữ ký được kết hợp thành một. Sự tổng hợp này cải thiện đáng kể hiệu suất quá trình đồng thuận của Ethereum. Tuy nhiên, cơ chế chữ ký này có một vấn đề cơ bản: nó dễ bị tấn công bởi máy tính lượng tử.
Các chữ ký BLS được sử dụng trong Beacon Chain của Ethereum dựa trên các đường cong elip. Tính bảo mật của các cơ chế chữ ký dựa trên đường cong elip dựa trên Bài toán Logarit rời rạc (DLP), mà sức mạnh tính toán vượt trội của máy tính lượng tử có thể thỏa hiệp. Điều này làm cho các chữ ký dựa trên đường cong elip vốn dễ bị tổn thương đối với các máy tính lượng tử.
Máy tính lượng tử đã tiến bộ rất nhanh, như được thấy qua các tiến bộ gần đây của Google với các vi mạch máy tính lượng tử như Willow. Google tuyên bố rằng Willow có thể thực hiện các phép tính trong 5 phút mà một siêu máy tính cần 10^25 năm để hoàn thành. Mặc dù điều này chưa đe dọa đến tính bảo mật của các đường cong Elliptic, nhưng những tiến bộ tiếp diễn với tốc độ này có thể đặt các hệ thống blockchain gặp nguy hiểm trong vài năm tới.
(Chuyển sang Tiêu chuẩn Mật mã Post-Quantum | Nguồn: NIST IR 8547)
Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST) đã bắt đầu nỗ lực chuẩn hóa các thuật toán chữ ký kháng lượng tử để giải quyết sự sụp đổ dự kiến của các hệ thống hiện có do máy tính lượng tử.
Ethereum cũng đang nghiêm túc xử lý vấn đề này. Trong Beam Chain, mục tiêu là đạt được các thuật toán chữ ký chống lại quantum.
Có một số loại chữ ký chống lượng tử, nhưng bài thuyết trình Beam Chain của Justin đặc biệt đề cập đến thuật toán chữ ký dựa trên băm. Khác với đường cong elip, chữ ký dựa trên băm không phụ thuộc vào cơ chế toán học, làm cho chúng khó bị máy tính lượng tử tấn công. Kết quả là, chữ ký dựa trên băm được coi là chống lượng tử và Beam Chain nhằm áp dụng những chữ ký như vậy.
Thách thức chính là chữ ký dựa trên hash thiếu tính chất tổng hợp có mặt trong chữ ký BLS. Ethereum phụ thuộc vào việc tổng hợp chữ ký trong quá trình đồng thuận để đạt hiệu suất. Mà không có tính tổng hợp, Ethereum sẽ không còn thể chứa được một tập người xác minh lớn.
ZK có thể được sử dụng để giải quyết vấn đề này. Nó liên quan đến việc tận dụng Proof Aggregation, một công nghệ kết hợp nhiều bằng chứng ZK thành một bằng chứng duy nhất. Cơ chế hoạt động như sau:
(Sơ đồ chứng minh tổng hợp | Nguồn: Figment Capital)
Phương pháp này cho phép Ethereum đạt được cùng hiệu suất như việc tổng hợp chữ ký BLS trong khi cũng đạt được khả năng chống lại lượng tử ở mức đồng thuận.
Tóm lại, chuỗi Beam với ZK sẽ mang lại những lợi ích sau đây:
Hệ thống chứng minh cơ bản ZK trong Beam Chain sẽ là zkVM. ZkVM dựa trên Risc-V cho phép chứng minh bất kỳ chương trình nào bằng bất kỳ ngôn ngữ nào, mang lại sự linh hoạt cao hơn.
(Trạng thái Beam chuyển đổi để biên dịch thành Risc-V và được chứng minh trong zkVMs | Nguồn: Thông báo Beam Chain từ Justin Drake)
Điều này tương thích tốt với hệ sinh thái khách hàng hiện tại của Ethereum, được phát triển bằng nhiều ngôn ngữ, bảo tồn tính đa dạng và sự dung sai của Ethereum. Trong tương lai, trên chuỗi Beam, các khách hàng khác nhau sẽ viết chức năng chuyển đổi trạng thái bằng nhiều ngôn ngữ lập trình, biên dịch nó thành Risc-V và cho phép nó được chứng minh trong bất kỳ zkVMs dựa trên Risc-V nào. Vì lý do này, zkVM là sự lựa chọn tự nhiên cho Chuỗi Beam.
Kết luận
Nếu Beam Chain được triển khai thành công, Ethereum có thể sẽ có các tính năng sau:
Hiện tại, Beam Chain chưa được công nhận chính thức là một phần của lộ trình của Ethereum. Việc triển khai nó sẽ đòi hỏi nghiên cứu, phát triển và thử nghiệm rộng lớn trong một khoảng thời gian dài. Tuy nhiên, nếu Ethereum tiếp tục với việc phân nhánh Beam Chain, những cải tiến về trải nghiệm người dùng kết quả có thể là quyết định.
Đây là kết luận của chúng tôi về cách Ethereum có thể phát triển trong năm năm tới thông qua góc nhìn của Beam Chain. Trong bài viết tiếp theo, chúng tôi sẽ xem xét Ethereum sẽ trông như thế nào vào năm 2025 từ hai góc độ: trải nghiệm người dùng và khả năng chống kiểm duyệt.
(Q): Đề xuất của Justin Drake đã được thảo luận riêng. Điều này có mâu thuẫn với giá trị cốt lõi của Ethereum là “mở” không?
(A): Không, không phải vậy. Đề xuất Beam Chain chỉ đơn giản là đề xuất thực hiện một số phần của lộ trình hiện tại của Ethereum một lần. Việc liệu nó sẽ được thực hiện hay không vẫn đòi hỏi cuộc thảo luận trong cộng đồng. Tất cả các chủ đề đã được thảo luận ở trên đã có các EIP hoặc bài viết liên quan trên Ethresear.ch. Điều này cũng cho thấy Beam Chain không phải là đề xuất đưa ra một hướng đi mới, chưa được tiết lộ trước đó cho Ethereum. Hơn nữa, các cuộc thảo luận liên quan đến lộ trình của Ethereum được tổ chức công khai trong cuộc gọi All Core Devs hàng hai tuần một lần, mà bất cứ ai cũng có thể tham gia. Nếu ai đó không đồng ý với lộ trình hoặc có ý tưởng mới, họ có thể đưa ra ý kiến của mình trong những cuộc gọi này hoặc nộp đề xuất mới dưới dạng EIP hoặc bài viết trên Ethresear.ch.
Tóm lại, đề xuất Beam Chain của Justin không phải là về việc thay đổi lộ trình mà là việc nhóm các phần của lộ trình dưới một tên hoặc meme duy nhất.
(Q): 5 năm có quá lâu để triển khai Beam Chain không?
(A): Năm năm có thể cảm thấy lâu nhưng cần xem xét hai yếu tố:
(Đa dạng máy khách thống nhất | Nguồn: Sự đa dạng của Ethereum Client)
Cơ chế đồng thuận của Ethereum tuân theo giao thức dựa trên BFT, trong đó nếu hơn một phần ba trình xác thực hoạt động khác với các trình xác thực khác, các khối không thể được hoàn thiện. Nếu Ethereum được xây dựng chỉ với một hoặc hai máy khách, bất kỳ lỗi nào trong các máy khách này đều có thể làm gián đoạn sản xuất khối. Do đó, Ethereum luôn hướng đến kiến trúc đa khách hàng được phát triển bằng nhiều ngôn ngữ lập trình. Sự đa dạng này được thể hiện rõ trong hệ sinh thái khách hàng hiện tại của Ethereum.
Như được hiển thị trong hình ảnh, tầng đồng thuận của Ethereum hiện đang hoạt động với ít nhất bốn khách hàng. Để thay thế Beacon Chain bằng Beam Chain, cả bốn nhóm khách hàng phải hợp tác trong quá trình phát triển. Xem xét điều này và tập đoàn xác minh lớn của Ethereum, quá trình phát triển Beam Chain phải ưu tiên tính ổn định và không thể được đẩy nhanh vào một khung thời gian vài tháng hoặc 1-2 năm.
Năm 2024, nhiều sự kiện quan trọng đã xảy ra xung quanh Ethereum. Đầu năm, Ethereum giới thiệu blobs thông qua bản nâng cấp Dencun. Cập nhật này đã giảm đáng kể chi phí giao dịch cho các rollup hiện có, tạo nền tảng cho sự mở rộng nhanh chóng của hệ sinh thái rollup.
(Giảm phí trong OP Chains sau nâng cấp Dencun | Nguồn:Optimism X)
Tuy nhiên, khi các dapp trong hệ sinh thái chuyển sang các mạng rollup và mạng Layer 1 (L1) thay thế có khả năng mở rộng cao, hoạt động của người dùng trên Ethereum bắt đầu giảm. Ngoài ra, khi các rollup ngưng nộp phí cao cho Ethereum, những lo ngại bắt đầu nảy sinh trong cộng đồng.
Ngoài ra, năm 2024 cũng là năm mà các nền tảng tập trung vào khả năng mở rộng L1 như Solana và Sui đã thể hiện sức mạnh đáng kể. Số lượng TPS (giao dịch trên giây) khổng lồ được tạo ra bởi những mạng này khiến hoạt động trên rollups dường như nhỏ bé.
Trong ngữ cảnh này, đã xuất hiện những lời chỉ trích, như “Lộ trình tập trung vào Ethereum của Ethereum có nhược điểm” hoặc “Sự phát triển của Ethereum quá chậm để thành công.” Ethereum thực sự đang trên đúng con đường? Ethereum sẽ trông như thế nào vào năm 2025 hoặc thậm chí là 2030?
Chuỗi bài viết này sẽ khám phá các phần của lộ trình của Ethereum dưới hai chủ đề chính, phân tích tương lai của nó dựa trên các chi tiết kỹ thuật. Chủ đề đầu tiên là Chuỗi Beam.
Nếu ai đó muốn chọn chủ đề được nói nhiều nhất trong cộng đồng Ethereum năm nay, có lẽ đó sẽ là thông báo về Beam Chain của nhà nghiên cứu Ethereum Justin Drake tại Devcon. Thông báo này đã thu hút rất nhiều sự quan tâm và, tương ứng, nhiều tiếng ồn. Hãy phân tích ý nghĩa của đề xuất này.
Ý tưởng cốt lõi của đề xuất Beam Chain là thiết kế lại hoàn toàn tầng phiên quyết Ethereum. Justin Drake đã trình bày ba lý do sau đây vì sao tầng phiên quyết hiện tại, Beacon Chain, cần được thiết kế lại:
Hiện tại, lộ trình lớp đồng thuận Ethereum bao gồm các yếu tố sau đây:
Trong số đó, bốn khu vực được đánh dấu đậm đại diện cho những thay đổi cơ bản vượt xa việc chỉ sửa đổi Beacon Chain. Ví dụ, snarkification của chuỗi đề cập đến việc chuyển đổi xử lý trạng thái của lớp đồng thuận thành công nghệ ZK, đòi hỏi những thay đổi cơ bản bắt đầu từ các hàm băm cho đến các phương pháp của merkleizing / serializing state.
Ngoài ra, các khe cắm nhanh hơn và sự hoàn thiện nhanh hơn là những thiết kế mới được đề xuất để đạt được cải tiến về hiệu suất trong khi vẫn duy trì tính bảo mật—một yếu tố không được ưu tiên trong các thiết kế ban đầu. Việc triển khai này đòi hỏi những sự thay đổi to lớn tại tầng đồng thuận.
Beam Chain đề xuất thực hiện những thay đổi này thông qua một hard fork duy nhất. Tóm lại:
Tiếp theo, chúng ta hãy khám phá cách thực hiện từng phần này và những tác động kỹ thuật mà chúng mang lại.
Hiện tại, thời gian khe của Ethereum là 12 giây, và mất 2-3 thời kỳ (khoảng 15 phút) để một khối được kết nối với khe đạt được sự hoàn thiện cuối cùng. Cải thiện thời gian này sẽ tác động tích cực đến người dùng, ứng dụng và rollups xây dựng trên Ethereum.
Chủ đề này, được biết đến trong cộng đồng nghiên cứu Ethereum với tên gọi là SSF (Single Slot Finality), nhằm mục tiêu rút ngắn thời gian để các khối Ethereum đạt đến tính cuối cùng từ khoảng 15 phút xuống còn 12 giây, cung cấp cho người dùng việc xác nhận nhanh hơn. Để hiểu về tính cuối cùng dựa trên một khe, chúng ta cần hiểu về thuật toán đồng thuận hiện tại của Ethereum, Gasper.
Một nguyên tắc thiết kế chính của Gasper là đảm bảo rằng một khối được đề xuất trong một khe đạt được một mức độ an ninh kinh tế nhất định sau một khoảng thời gian nhất định trong khi giảm thiểu tải truyền thông trên mỗi người xác minh. Để đạt được điều này, Ethereum chia toàn bộ bộ xác minh thành các ủy ban phân phối trên 32 khe. Mỗi khe có thể chứa đến 64 ủy ban, và mục tiêu là hình thành mỗi ủy ban từ 128 người xác minh (mặc dù số này có thể tăng nếu tổng số người xác minh hoạt động vượt quá điều này).
Các validator trong mỗi ủy ban độc lập xác minh khối và bỏ phiếu trên đó bằng chữ ký BLS. Cơ chế chữ ký BLS cho phép nhiều chữ ký được tổng hợp thành một, có nghĩa là một nút được chỉ định trong ủy ban thu thập những chữ ký này và biên soạn chúng thành một gói dữ liệu nhỏ gọn duy nhất. Bằng cách phát sóng chữ ký tổng hợp này, người đề xuất khối tiếp theo có thể xác nhận với dữ liệu tối thiểu rằng khối đã được xác minh đúng cách.
(Tích hợp chữ ký BLS giữa các nhà xác thực trên Ethereum | Nguồn: eth2book)
Tóm lại, Gasper của Ethereum đạt được cả sự mở rộng khả năng và an ninh kinh tế thông qua các cơ chế sau:
Tuy nhiên, một vấn đề nảy sinh là Gasper hoạt động trên cơ sở kỷ nguyên, và ‘kết nối’ giữa các kỷ nguyên phải được xác minh trước khi một khe có thể đạt được tính chất cuối cùng. Trong Gasper, tối thiểu hai kỷ nguyên (64 khe) phải trôi qua trước khi đạt được tính chất cuối cùng tương đương với an ninh kinh tế hoàn chỉnh của Ethereum.
Điều này dẫn đến biểu đồ đại diện sau:
(Economic Finality at Gasper | Source:Orbit SSF)
Điều này đưa ra nhiều thách thức khác nhau và làm giảm UX. Ví dụ:
Ví dụ, vào tháng 3 năm 2024, Polygon zkEVM đã gặp sự cố gián đoạn chuỗi kéo dài hơn hai ngày do xử lý không đúng của Ethereum reorg.
Giảm thời gian để hoàn thiện không phải là điều không thể, như đã được chứng minh bởi các thuật toán đồng thuận như Tendermint, đã được áp dụng trong một số giao thức. Tuy nhiên, thách thức khi áp dụng cơ chế Tendermint nằm ở việc giao tiếp P2P thường xuyên giữa các nút, gây ra hạn chế về khả năng mở rộng.
Trong Tendermint, nếu số lượng node là N, độ phức tạp thông điệp của nó là O(N^3). Điều này có nghĩa là khi số lượng node tăng lên, tần suất giao tiếp giữa chúng tăng một cách mũ, hạn chế tính mở rộng. Do đó, các giao thức như Ethereum, với nhiều người xác minh, không thể trực tiếp áp dụng Tendermint như hiện tại.
Cần phải thực hiện công việc bổ sung để giải quyết những vấn đề này để áp dụng sự đồng thuận kiểu Tendermint cho Ethereum.
Orbit SSF nhằm sửa đổi cơ chế ủy ban Gasper để giảm thời gian cho sự cuối cùng của khe hở trong khi duy trì an ninh kinh tế cao.
Đề xuất là giảm kích thước epoch từ 32 khe cắm xuống một khe cắm duy nhất (~12 giây). Tuy nhiên, như đã đề cập trước đó, điều này sẽ tăng tài nguyên sử dụng cho việc giao tiếp của người xác thực, ảnh hưởng tiêu cực đến sự phân quyền của Ethereum.
Để giải quyết vấn đề này, Orbit SSF đề xuất những ý tưởng sau:
Tăng mức tối đa số tiền cược cho mỗi Ethereum validator có thể đạt được cùng mức độ bảo mật kinh tế với ít hơn số lượng validators.
Thay vì việc có nhiều đoạn thảo cho một khe, Orbit SSF đề xuất giới thiệu một “sàn quyền siêu” duy nhất. Người xác minh với số lượng cục lớn hơn sẽ gần như luôn luôn được bao gồm một cách tệ nhân trong đoạn thảo, đảm bảo rằng cùng một mục độ an ninh kinh tế được duy trì ngay cả khi có ít đoạn thảo hơn.
Bản nâng cấp Ethereum tiếp theo, Pectra, bao gồm EIP-7251, đề xuất tăng mức tối đa cho số tiền đặt cược (MaxEB) của các nhà xác minh từ 32 ETH lên 2048 ETH. Mặc dù đề xuất này hấp dẫn đối với các nhà vận hành cơ sở hạ tầng Ethereum, nó cũng là một điều kiện tiên quyết cho Orbit SSF.
Tuy nhiên, nếu những người xác minh có số lượng cọc lớn thường được bao gồm trong các ủy ban, những người xác minh đơn lẻ nhỏ hơn có thể gặp phải giảm phần thưởng, tiềm năng gây hại đến sự phân quyền của Ethereum. Để ngăn chặn điều này, Orbit SSF điều chỉnh phần thưởng để tỷ suất tăng tuyến tính theo số lượng cọc trong khi đảm bảo rằng những người xác minh lớn hơn được bao gồm trong các ủy ban thường xuyên hơn.
(Phần thưởng và Xác suất được đưa vào ủy ban trong Orbit SSF | Nguồn:Orbit SSF)
Ngoài ra, Orbit SSF chuyển đổi sang “sự quyết định dựa trên ủy ban.” Trong Gasper, các ủy ban chỉ có thể đóng góp vào sự quyết định sau khi đã qua hai hoặc nhiều thời kỳ, nhưng Orbit SSF cho phép mỗi ủy ban được gán khe có thể đóng góp vào sự quyết định trong thời gian thực. Nó nhằm mục tiêu làm cho các ủy ban trở thành những người đóng góp tích cực hơn vào sự quyết định và đạt được tính mở rộng nhanh hơn.
(Finality in Orbit SSF sử dụng Cap-and-slow-rotate | Nguồn:Orbit SSF)
Chìa khóa ở đây nằm ở việc tổ chức thành viên hội đồng. Orbit SSF đề xuất một cơ chế “quay chậm” trong đó các thợ đạo đại biểu có cổ phần lớn gần như cố định trong các hội đồng trong khi các thợ đạo nhỏ được xoay vào và ra khỏi. Điều này cho phép giá trị của F, đại diện cho ngưỡng an ninh kinh tế, được đặt rất cao trong khi duy trì giao tiếp tối thiểu giữa các thợ đạo và đảm bảo thời gian cuối cùng vẫn giữ ở mức thấp.
Ví dụ, đặt n = 3 và một F đáng kể lớn sẽ cho phép Ethereum đạt được tính cuối cùng trong khoảng ba khe, từ đó thực hiện được tầm nhìn 3-slot FFG của Justin Drake.
Tuy nhiên, việc nâng F lên mức của toàn bộ tập hợp xác minh của Ethereum không dễ dàng. Điều này có thể giảm chi phí thực hiện cuộc tấn công 51% trên Ethereum. Do đó, thách thức chính đối với Orbit SSF trong tương lai là xác định cách tăng F một cách kỹ thuật để đảm bảo rằng sự an toàn của Ethereum vẫn mạnh mẽ mà không cần phải hy sinh quá nhiều sự phi tập trung.
Thời gian khe cắm ngắn hơn (khe cắm 4 giây)Ngay cả khi SSF (hoặc độ tin cậy 3 khe cắm) được đạt được, người dùng Ethereum vẫn sẽ gặp thời gian xác nhận giao dịch tối thiểu là 12 giây. Điều này dẫn đến hai hạn chế chính đối với người dùng:
Ngoài ra, thời gian khối 12 giây đặc biệt bất lợi cho rollups, đặc biệt là rollups dựa trên. Ví dụ, Taiko triển khai một rollup dựa trên bằng cách đăng mỗi khối L2 lên L1. Kết quả, thời gian khối của Taiko có thể tăng lên tối thiểu 12 giây và đôi khi vượt quá 24 giây.
Đã có hai giải pháp được đề xuất để giải quyết vấn đề này:
a. Giảm thời gian khối Ethereum xuống 4 hoặc 8 giây
b. Sử dụng trước khi xác nhận
Việc giảm thời gian khối Ethereum đang là chủ đề được thảo luận tích cực. Đã được hình thành dưới dạng EIP-7782, đề xuất giảm thời gian khe từ 12 giây xuống 8 giây, qua đó tăng khả năng mở rộng của Ethereum lên 33%. Tuy nhiên, một thời gian khe 8 giây có thể không phải là tối ưu cho trải nghiệm người dùng hoặc dựa trên rollups. Việc đạt được một thời gian khe ngắn hơn dường như hấp dẫn hơn.
Tuy nói vậy, thời gian khối ngắn có thể dẫn đến sự tập trung tăng của bộ xác thực. Do hạn chế về vật lý, các bộ xác thực cách xa địa lý gặp phải thời gian truyền thông lâu hơn, và thời gian khe 4 giây có thể làm cho việc truyền thông trở nên không khả thi trong một số tình huống.
Thống kê thời gian truyền khối của mainnet Ethereum cung cấp cái nhìn về khả năng thực hiện thời gian khối 4 giây. Biểu đồ dưới đây cho thấy phân phối thời gian truyền khối.
(CDF thời gian đến tin nhắn | Nguồn:Độ trễ truyền tin Gossipsub)
Khoảng 98% khối được truyền tải trong vòng 4 giây, trong khi khoảng 2% mất thời gian lâu hơn. Dựa trên dữ liệu này, thời gian khối 4 giây có thể khả thi. Tuy nhiên, thời gian khối không chỉ bao gồm giao tiếp mà còn bao gồm thực thi và bỏ phiếu. Xem xét những yếu tố này, chỉ có khoảng 2 giây trong thời gian khối 4 giây sẽ có sẵn để giao tiếp. Trong điều kiện này, việc đạt được thời gian khối 4 giây là thách thức.
Để giải quyết vấn đề này, kích thước dữ liệu truyền phải được giảm xuống, hiệu suất của các thành phần P2P trong các máy khách phải được tối đa hóa, hoặc giao tiếp vật lý phải trở nên hiệu quả hơn.
Trong thời gian chờ đợi, việc xác nhận trước có thể cải thiện trải nghiệm người dùng. Xác nhận trước cho phép các thực thể sản xuất khối hứa với người dùng, “Giao dịch của bạn sẽ được bao gồm trong khối tiếp theo,” mang lại kết quả cho người dùng nhanh hơn thời gian khe.
Lợi ích của việc xác nhận trước là các nhà xác nhận L1 có thể sử dụng nó mà không cần yêu cầu một sự chia tách hoặc sửa đổi khách hàng. Ví dụ, Commit-Boost là phần mềm cho phép các nhà xác nhận Ethereum tạo và truyền đi các xác nhận trước một cách an toàn.
Commit-Boost, giống như MEV-Boost, là một bên phụ tùy chọn cho các validators, cho phép họ sinh ra và lan truyền “commitments” một cách an toàn. Tùy thuộc vào trường hợp sử dụng, những commitments này có thể có nhiều hình thức khác nhau:
Sử dụng kiến trúc tiền xác nhận loại ba, thời gian chờ đợi được cảm nhận của người dùng có thể giảm đáng kể ngay cả khi có thời gian khối dài hơn. Khi một người xác nhận nhận được giao dịch của người dùng, họ có thể thực hiện và trả kết quả cho người dùng. Vì kết quả này dựa trên cam kết của người xác nhận và không phải việc tạo khối, người dùng có thể nhận được nó trong vài mili giây.
Tuy nhiên, hiệu quả của Commit-Boost phụ thuộc vào việc các nhà xác minh sử dụng nó. Nếu chỉ có một số ít nhà xác minh sử dụng nó, tác động lên trải nghiệm người dùng sẽ rất nhỏ. Tuy nhiên, Commit-Boost đã nhận được sự ủng hộ mạnh mẽ từ cộng đồng Ethereum và có tiềm năng trở thành một middleware phổ biến như MEV-Boost. Nó đã nhận được sự ủng hộ từ các nhà điều hành xác minh nổi tiếng như Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41 và Figment. Ngoài ra, nó đã nhận được các hỗ trợ từ EF, Lido và Eigenlayer và được sự hỗ trợ mạnh mẽ từ nhà xây dựng khối Titan.
Tuy nhiên, như đã đề cập trước đó, việc xác nhận trước có khả năng được sử dụng như một off-chain sidecar như MEV-Boost hơn là được tích hợp trực tiếp vào giao thức.
Vai trò của Beam Chain trong việc tăng tốc khe cắm
Như đã thảo luận trong bài thuyết trình của Justin Drake, mục tiêu của Beam Chain là giảm thời gian khối. Do đó, nghiên cứu và triển khai có thể tập trung vào việc giảm thời gian khe cắm xuống 4 giây mà không đánh đổi tính phân quyền. Điều này có thể được giải quyết bằng cách tối ưu hóa toàn bộ Ethereum, sẽ được giải thích trong phần cuối của bài viết này.
Trong bài thuyết trình của mình, Justin đã nói rằng mục tiêu của Beam Chain là sử dụng công nghệ ZK để snarkify consensus client. Điều này có nghĩa là gì, làm thế nào để đạt được và tại sao lại cần thiết?
Hiện tại, Beacon Chain của Ethereum đạt được sự nhất quán bằng cách yêu cầu các nhà xác minh ‘thực hiện lại’ mỗi khối để xác minh rằng rễ trạng thái kết quả là chính xác. Quá trình thực hiện lại này gây ra hiệu suất kém và làm như một rào cản cho việc giảm yêu cầu phần cứng cho nhà xác minh.
Beam Chain nhằm thay thế quá trình thực hiện lại này bằng quá trình “xác minh” sử dụng công nghệ ZK. Điều này sẽ giảm đáng kể yêu cầu về phần cứng cho các bên xác minh và cho phép bất kỳ ai cũng có thể chạy một nút Ethereum từ bất cứ đâu. Để đạt được điều này, Beam Chain và Ethereum sẽ sử dụng ZK SNARKs.
ZK SNARKs có hai thuộc tính sau:
Ý tưởng là áp dụng ZK vào các tính toán và dữ liệu cần thiết cho sự đồng thuận trong Ethereum, tạo ra chứng minh rằng logic đã được tuân theo. Điều này có nghĩa là các người xác minh có thể đạt được sự đồng thuận bằng cách xác minh chứng minh ZK thay vì thực hiện lại toàn bộ khối và lưu trữ trạng thái cập nhật. Việc xác minh chứng minh ZK hiệu quả hơn rất nhiều về kích thước dữ liệu và tính mở rộng so với việc thực hiện lại.
Kết quả là, yêu cầu về phần cứng cho các máy chủ Ethereum có thể được giảm đáng kể. Ví dụ, Vitalik đã cho biết trong bài viết trên The Verge rằng mục tiêu là cho phép các máy chủ hoạt động ngay cả trên môi trường có tài nguyên hạn chế như đồng hồ thông minh.
Bước đầu tiên là biến chuyển chức năng trạng thái thành dạng snark. Chức năng chuyển trạng thái thường có dạng như sau:
f(S,B)=S’
Ở đây:
Tất cả các chuỗi khối đều dựa trên các hàm chuyển trạng thái xác định, và Ethereum cũng không nằm ngoài quy tắc đó. Ethereum có các hàm chuyển trạng thái khác nhau cho các lớp consensus và thực thi của mình. Việc Snarkifying cả hai này sẽ khiến việc xác minh toàn bộ hệ thống Ethereum trở nên có thể thông qua ZK, từ đó cho phép các bộ xác minh siêu nhẹ hoàn toàn.
Trong Beam Chain, mục tiêu là làm cho chức năng chuyển đổi trạng thái của lớp đồng thuận trở nên snarkify. Hiện tại, chức năng chuyển đổi trạng thái trong lớp đồng thuận của Ethereum được thực hiện trong mỗi khe và thực hiện các hành động sau:
Hàm này được thực thi mỗi khi một validator nhận được một khối từ một validator khác. Nếu hàm này được snarkified, các validator sẽ không còn cần thực thi hàm chuyển trạng thái trực tiếp nữa. Thay vào đó, họ có thể xác minh một bằng chứng cho thấy rằng hàm đã được thực thi đúng.
Trong trường hợp này, ai tạo ra chứng minh ZK? Thông thường, người đề xuất của khối cũng có trách nhiệm tạo ra chứng minh ZK. Tuy nhiên, điều quan trọng cần lưu ý là không phải tất cả các nhà xác minh đều có thể tạo ra chứng minh ZK.
Beam Chain nhằm đạt hiệu năng mà một ZK proof có thể được tạo ra trong vòng 3 giây trên một laptop tiêu chuẩn. Tuy nhiên, ngay cả khi mục tiêu này được đạt, các validator chạy trên các thiết bị như smartwatch hoặc điện thoại thông minh có thể không có đủ tài nguyên để tạo ra ZK proof.
Ở đây, mạng có thể dựa vào lòng vị tha. Chỉ cần một bằng chứng ZK cho quá trình chuyển đổi trạng thái của lớp đồng thuận được tạo ra cho mỗi khối, và không nhất thiết phải do người đề xuất khối tạo ra. Nói cách khác, miễn là ít nhất một thực thể trong mạng tạo ra một bằng chứng ZK cho mỗi khối, nó có thể đảm bảo rằng các khối của Beam Chain được tạo ra đúng.
Chính sự thay đổi này có thể không cải thiện đáng kể hiệu suất của bộ xác thực. Hàm chuyển trạng thái của lớp đồng thuận liên quan đến các hoạt động nhẹ hơn so với hàm chuyển trạng thái của lớp thực thi. Tuy nhiên, điểm nghẽn chính không nằm ở tài nguyên cần thiết để thực thi hàm chuyển trạng thái mà nằm ở băng thông mạng. Bộ xác thực gặp khó khăn trong việc đạt được sự đồng thuận trong khoảng thời gian đã được cấp phát khi kích thước dữ liệu (khối) mà họ trao đổi tăng lên. Đây là một trong những lý do mà Ethereum đã duy trì giới hạn gas là 30 triệu trong ba năm qua.
Nếu thay đổi này được thực hiện song song với việc sử dụng SNARK cho lớp thực thi, các validator chỉ cần trao đổi một lượng dữ liệu nhỏ hơn nhiều so với toàn bộ khối. Điều này là do chứng thực SNARK có kích thước nhỏ hơn rất nhiều so với dữ liệu gốc. Các validator Ethereum được hoàn toàn chứng thực SNARK sẽ trao đổi ít dữ liệu hơn, giảm yêu cầu mạng so với hệ thống hiện tại.
Tóm lại, sau đây là những lợi ích của việc snarkification đầy đủ của Ethereum cho các máy chủ xác thực.
Kết quả là hệ sinh thái Ethereum có thể thay đổi một cách đáng kể. Ví dụ:
Điều này sẽ làm cho việc tham gia của validator dễ dàng hơn và phi tập trung hơn.
Việc snarkify hóa hàm chuyển trạng thái liệu có đủ để làm lớp đồng thuận của Beam Chain không?
Có một lĩnh vực khác mà Beam Chain nhắm đến: quá trình tạo chữ ký. Lớp đồng thuận Ethereum hiện tại sử dụng chữ ký của những người xác thực làm dữ liệu xác nhận để hoàn thiện các khối và xác định chuỗi chính xác trong trường hợp có sự phân nhánh.
Hiện tại, Ethereum sử dụng chữ ký BLS cho mục đích này, như đã được giải thích trước đây, có tính chất tổng hợp, cho phép nhiều chữ ký được kết hợp thành một. Sự tổng hợp này cải thiện đáng kể hiệu suất quá trình đồng thuận của Ethereum. Tuy nhiên, cơ chế chữ ký này có một vấn đề cơ bản: nó dễ bị tấn công bởi máy tính lượng tử.
Các chữ ký BLS được sử dụng trong Beacon Chain của Ethereum dựa trên các đường cong elip. Tính bảo mật của các cơ chế chữ ký dựa trên đường cong elip dựa trên Bài toán Logarit rời rạc (DLP), mà sức mạnh tính toán vượt trội của máy tính lượng tử có thể thỏa hiệp. Điều này làm cho các chữ ký dựa trên đường cong elip vốn dễ bị tổn thương đối với các máy tính lượng tử.
Máy tính lượng tử đã tiến bộ rất nhanh, như được thấy qua các tiến bộ gần đây của Google với các vi mạch máy tính lượng tử như Willow. Google tuyên bố rằng Willow có thể thực hiện các phép tính trong 5 phút mà một siêu máy tính cần 10^25 năm để hoàn thành. Mặc dù điều này chưa đe dọa đến tính bảo mật của các đường cong Elliptic, nhưng những tiến bộ tiếp diễn với tốc độ này có thể đặt các hệ thống blockchain gặp nguy hiểm trong vài năm tới.
(Chuyển sang Tiêu chuẩn Mật mã Post-Quantum | Nguồn: NIST IR 8547)
Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST) đã bắt đầu nỗ lực chuẩn hóa các thuật toán chữ ký kháng lượng tử để giải quyết sự sụp đổ dự kiến của các hệ thống hiện có do máy tính lượng tử.
Ethereum cũng đang nghiêm túc xử lý vấn đề này. Trong Beam Chain, mục tiêu là đạt được các thuật toán chữ ký chống lại quantum.
Có một số loại chữ ký chống lượng tử, nhưng bài thuyết trình Beam Chain của Justin đặc biệt đề cập đến thuật toán chữ ký dựa trên băm. Khác với đường cong elip, chữ ký dựa trên băm không phụ thuộc vào cơ chế toán học, làm cho chúng khó bị máy tính lượng tử tấn công. Kết quả là, chữ ký dựa trên băm được coi là chống lượng tử và Beam Chain nhằm áp dụng những chữ ký như vậy.
Thách thức chính là chữ ký dựa trên hash thiếu tính chất tổng hợp có mặt trong chữ ký BLS. Ethereum phụ thuộc vào việc tổng hợp chữ ký trong quá trình đồng thuận để đạt hiệu suất. Mà không có tính tổng hợp, Ethereum sẽ không còn thể chứa được một tập người xác minh lớn.
ZK có thể được sử dụng để giải quyết vấn đề này. Nó liên quan đến việc tận dụng Proof Aggregation, một công nghệ kết hợp nhiều bằng chứng ZK thành một bằng chứng duy nhất. Cơ chế hoạt động như sau:
(Sơ đồ chứng minh tổng hợp | Nguồn: Figment Capital)
Phương pháp này cho phép Ethereum đạt được cùng hiệu suất như việc tổng hợp chữ ký BLS trong khi cũng đạt được khả năng chống lại lượng tử ở mức đồng thuận.
Tóm lại, chuỗi Beam với ZK sẽ mang lại những lợi ích sau đây:
Hệ thống chứng minh cơ bản ZK trong Beam Chain sẽ là zkVM. ZkVM dựa trên Risc-V cho phép chứng minh bất kỳ chương trình nào bằng bất kỳ ngôn ngữ nào, mang lại sự linh hoạt cao hơn.
(Trạng thái Beam chuyển đổi để biên dịch thành Risc-V và được chứng minh trong zkVMs | Nguồn: Thông báo Beam Chain từ Justin Drake)
Điều này tương thích tốt với hệ sinh thái khách hàng hiện tại của Ethereum, được phát triển bằng nhiều ngôn ngữ, bảo tồn tính đa dạng và sự dung sai của Ethereum. Trong tương lai, trên chuỗi Beam, các khách hàng khác nhau sẽ viết chức năng chuyển đổi trạng thái bằng nhiều ngôn ngữ lập trình, biên dịch nó thành Risc-V và cho phép nó được chứng minh trong bất kỳ zkVMs dựa trên Risc-V nào. Vì lý do này, zkVM là sự lựa chọn tự nhiên cho Chuỗi Beam.
Kết luận
Nếu Beam Chain được triển khai thành công, Ethereum có thể sẽ có các tính năng sau:
Hiện tại, Beam Chain chưa được công nhận chính thức là một phần của lộ trình của Ethereum. Việc triển khai nó sẽ đòi hỏi nghiên cứu, phát triển và thử nghiệm rộng lớn trong một khoảng thời gian dài. Tuy nhiên, nếu Ethereum tiếp tục với việc phân nhánh Beam Chain, những cải tiến về trải nghiệm người dùng kết quả có thể là quyết định.
Đây là kết luận của chúng tôi về cách Ethereum có thể phát triển trong năm năm tới thông qua góc nhìn của Beam Chain. Trong bài viết tiếp theo, chúng tôi sẽ xem xét Ethereum sẽ trông như thế nào vào năm 2025 từ hai góc độ: trải nghiệm người dùng và khả năng chống kiểm duyệt.
(Q): Đề xuất của Justin Drake đã được thảo luận riêng. Điều này có mâu thuẫn với giá trị cốt lõi của Ethereum là “mở” không?
(A): Không, không phải vậy. Đề xuất Beam Chain chỉ đơn giản là đề xuất thực hiện một số phần của lộ trình hiện tại của Ethereum một lần. Việc liệu nó sẽ được thực hiện hay không vẫn đòi hỏi cuộc thảo luận trong cộng đồng. Tất cả các chủ đề đã được thảo luận ở trên đã có các EIP hoặc bài viết liên quan trên Ethresear.ch. Điều này cũng cho thấy Beam Chain không phải là đề xuất đưa ra một hướng đi mới, chưa được tiết lộ trước đó cho Ethereum. Hơn nữa, các cuộc thảo luận liên quan đến lộ trình của Ethereum được tổ chức công khai trong cuộc gọi All Core Devs hàng hai tuần một lần, mà bất cứ ai cũng có thể tham gia. Nếu ai đó không đồng ý với lộ trình hoặc có ý tưởng mới, họ có thể đưa ra ý kiến của mình trong những cuộc gọi này hoặc nộp đề xuất mới dưới dạng EIP hoặc bài viết trên Ethresear.ch.
Tóm lại, đề xuất Beam Chain của Justin không phải là về việc thay đổi lộ trình mà là việc nhóm các phần của lộ trình dưới một tên hoặc meme duy nhất.
(Q): 5 năm có quá lâu để triển khai Beam Chain không?
(A): Năm năm có thể cảm thấy lâu nhưng cần xem xét hai yếu tố:
(Đa dạng máy khách thống nhất | Nguồn: Sự đa dạng của Ethereum Client)
Cơ chế đồng thuận của Ethereum tuân theo giao thức dựa trên BFT, trong đó nếu hơn một phần ba trình xác thực hoạt động khác với các trình xác thực khác, các khối không thể được hoàn thiện. Nếu Ethereum được xây dựng chỉ với một hoặc hai máy khách, bất kỳ lỗi nào trong các máy khách này đều có thể làm gián đoạn sản xuất khối. Do đó, Ethereum luôn hướng đến kiến trúc đa khách hàng được phát triển bằng nhiều ngôn ngữ lập trình. Sự đa dạng này được thể hiện rõ trong hệ sinh thái khách hàng hiện tại của Ethereum.
Như được hiển thị trong hình ảnh, tầng đồng thuận của Ethereum hiện đang hoạt động với ít nhất bốn khách hàng. Để thay thế Beacon Chain bằng Beam Chain, cả bốn nhóm khách hàng phải hợp tác trong quá trình phát triển. Xem xét điều này và tập đoàn xác minh lớn của Ethereum, quá trình phát triển Beam Chain phải ưu tiên tính ổn định và không thể được đẩy nhanh vào một khung thời gian vài tháng hoặc 1-2 năm.