Eclipse Mainnet: Mô hình L2 mới kết hợp công nghệ Solana và Ethereum, dung hòa ưu điểm từ nhiều nền tảng
Tuyển chọn TechFlowTuyển chọn TechFlow
Eclipse Mainnet: Mô hình L2 mới kết hợp công nghệ Solana và Ethereum, dung hòa ưu điểm từ nhiều nền tảng
L2 có khả năng đáng kinh ngạc trong việc tận dụng hiệu ứng mạng và đảm bảo thanh toán của Ethereum, đồng thời thử nghiệm các môi trường thực thi mới tốt nhất, Eclipse Mainnet là hiện thực tự nhiên của tầm nhìn này.
Chuyên sâu báo cáo Web3Tác giả: Eclipse
Biên dịch: TechFlow
Eclipse Mainnet là một lớp Layer 2 phổ quát kết hợp những phần tốt nhất của kiến trúc mô-đun:
-
Lớp thanh toán: Ethereum - Eclipse sẽ thanh toán với Ethereum (tức là cầu nối xác thực sẽ nằm trên Ethereum) và sử dụng ETH làm token gas.
-
Lớp thực thi: Máy ảo Solana (SVM) - Eclipse sẽ chạy SVM hiệu suất cao làm môi trường thực thi.
-
Khả năng truy cập dữ liệu: Celestia - Eclipse sẽ công bố dữ liệu của mình lên Celestia để đạt được khả năng truy cập dữ liệu (DA) có thể mở rộng.
-
Xác minh: RISC Zero - Eclipse sẽ sử dụng RISC Zero để tạo bằng chứng chống gian lận dạng zero-knowledge (mà không cần tuần tự hóa trạng thái trung gian!)
Phần lớn điểm nổi bật của Eclipse tập trung vào việc triển khai các rollup riêng cho từng ứng dụng, nhưng hiện nay rõ ràng hơn bao giờ hết rằng Ethereum cần một Layer 2 phổ quát có thể đạt được quy mô thật sự. Hầu hết các ứng dụng sẽ không hưởng lợi từ việc tùy chỉnh chuỗi riêng, và hệ quả là sự phân mảnh và phức tạp này thực tế có thể dẫn đến trải nghiệm người dùng và nhà phát triển tồi tệ hơn.
Thường tồn tại một nghịch lý sai lầm giữa tầm nhìn rollup mô-đun và khả năng của một chuỗi đơn duy nhất có thể mở rộng quy mô lớn, thực thi song song và chia sẻ trạng thái. “Mô-đun” thường bị nhầm lẫn với “riêng cho ứng dụng”, điều này khiến người ta tưởng rằng rollup đồng nghĩa với một thế giới gồm nhiều chuỗi nhỏ lẻ, phân mảnh và thông lượng thấp.
Lớp thực thi: Tốc độ và quy mô của Solana
Eclipse Mainnet sẽ áp dụng môi trường thực thi tương tự như Solana – loại tối ưu nhất. Điều này mang lại những lợi thế to lớn:
Thực thi song song được tối ưu hóa
SVM cùng thời gian chạy Sealevel của nó nổi tiếng vì hỗ trợ thực thi giao dịch song song. Các giao dịch không chạm vào trạng thái trùng lặp có thể được xử lý song song thay vì tuần tự.
Điều này cho phép SVM mở rộng trực tiếp theo phần cứng, vì bộ xử lý liên tục thêm nhiều nhân hơn với chi phí thấp hơn. Môi trường chạy đơn luồng (như EVM hiện nay) về bản chất sẽ không hưởng lợi từ việc giảm chi phí mỗi nhân. Trong hơn một thập kỷ qua, sự cải thiện hiệu suất đơn luồng đã giảm dần đều. Gần như mọi cải tiến vẫn đến từ việc tăng số lượng nhân, do đó tận dụng xu hướng này để song song hóa khối lượng công việc là rất quan trọng:
Mặc dù đã có một vài nỗ lực sơ khai nhằm song song hóa EVM, nhưng việc thêm tính năng này trong khi vẫn giữ tính tương thích sẽ đặt ra những sự đánh đổi cơ bản, bao gồm hiệu suất kém nếu không giải quyết các điểm nghẽn khác (ví dụ như tăng trưởng trạng thái). Việc các hợp đồng khai báo trước phụ thuộc trạng thái (như trong SVM) cho phép song song hóa tối ưu.
Thị trường phí gốc
Hiện nay, hầu hết thị trường phí đều mang tính toàn cục, nghĩa là một ứng dụng hot sẽ làm tăng phí cho tất cả người dùng trên chuỗi. Một lần đúc NFT không nên khiến cả chuỗi trở nên vô dụng đối với mọi thứ khác. Công việc tuyệt vời của Solana về thị trường phí gốc đã giải quyết vấn đề tranh chấp trạng thái giữa các ứng dụng này. Trong phiên bản hiện tại, bộ lập lịch sẽ ưu tiên các giao dịch không xung đột, cho phép các giao dịch không xung đột được thực hiện với phí thấp hơn. Về lâu dài, thị trường phí gốc sẽ được tích hợp ở cấp giao thức. Điều này đảm bảo rằng tình trạng phí tăng vọt của một ứng dụng riêng lẻ sẽ không ảnh hưởng đến phần còn lại của chuỗi.
Thị trường phí gốc tận dụng lợi thế từ môi trường chạy song song độc đáo của Solana. Việc cố gắng triển khai thị trường phí gốc cho các điểm nóng trạng thái trong EVM bằng các phương pháp heuristic (tức là không khai báo trước việc truy cập trạng thái) sẽ dẫn đến sự kém hiệu quả và các vector tấn công tiềm tàng.
Cũng đang có một số nghiên cứu ban đầu đang diễn ra, nhằm giúp các ứng dụng dễ dàng nội bộ hóa giá trị gốc của chính chúng, điều mà ngày nay thường đòi hỏi sự sáng tạo hơn trong thiết kế ở cấp ứng dụng.
Quản lý tăng trưởng trạng thái
Trước khi EVM thậm chí gặp phải vấn đề về thực thi tuần tự làm điểm nghẽn, thì tăng trưởng trạng thái đã là điểm nghẽn cấp bách hơn nhiều.
Vì trạng thái không dùng cây Merkle, Solana không chịu chi phí cập nhật cây Merkle mỗi lần cập nhật trạng thái. Thay vào đó, toàn bộ trạng thái sẽ được lưu trữ sau mỗi kỷ nguyên (2,5 ngày). Cách này rẻ hơn so với việc lưu trữ theo thời gian thực (như trong EVM).
Quan trọng hơn, EVM có quyền truy cập tài khoản động (tức là giao dịch có thể chạm tới bất kỳ trạng thái nào theo nhu cầu). Việc tìm kiếm trạng thái động này nghĩa là trạng thái không thể được tải vào bộ nhớ trước khi thực thi. Trong SVM, mỗi giao dịch đều chỉ định tất cả trạng thái cần thiết để thực thi.
Do đó, kích thước trạng thái sẽ không ảnh hưởng đến việc thực thi SVM. Giả sử trình xác thực nâng cấp ổ đĩa lưu trữ mỗi hai năm, mạng có thể an toàn tăng gấp đôi kích thước snapshot mỗi hai năm mà không gặp vấn đề nghiêm trọng nào.
Hơn nữa, các nhóm như Helius đang tích cực cải thiện khả năng truy cập dữ liệu lịch sử và giảm kích thước trạng thái thông qua nén.
Tương thích EVM
Neon EVM là một máy ảo Ethereum dưới dạng hợp đồng thông minh có thể triển khai trên bất kỳ chuỗi SVM nào. Điều này mang lại khả năng tương thích EVM đầy đủ cho Eclipse Mainnet (bao gồm hỗ trợ bytecode EVM và JSON-RPC của Ethereum), với thông lượng vượt quá EVM đơn luồng. Vì mỗi instance Neon EVM đều có thị trường phí gốc riêng, các ứng dụng có thể đơn giản triển khai hợp đồng riêng để hưởng lợi ích của chuỗi dành riêng cho ứng dụng, mà không làm hỏng UX, bảo mật hay thanh khoản.
Ngoài ra, trình biên dịch Solang có thể biên dịch mã hợp đồng thông minh Solidity thành bytecode SVM.
MetaMask Snaps
Việc hướng dẫn người dùng EVM chuyển sang các chuỗi phi-EVM luôn là một rào cản lớn, nhưng MetaMask Snaps vừa được công bố gần đây sẽ phá vỡ rào cản này. Người dùng EVM có thể tiếp tục dùng MetaMask mà không cần chuyển ví. Nhờ đóng góp mã nguồn mở tuyệt vời từ Drift xây dựng một triển khai MetaMask Snaps xuất sắc, trải nghiệm sử dụng tương tự như tương tác với bất kỳ chuỗi EVM nào. Người dùng Eclipse Mainnet sẽ có thể tương tác bản địa với các ứng dụng bên trong MetaMask, hoặc dùng các ví gốc Solana như Salmon.
Firedancer
Firedancer là client Solana được Jump phát triển, đang được mong đợi rất nhiều, nhằm tăng đáng kể thông lượng, tính đàn hồi và hiệu quả của mạng. Khi khởi chạy, chúng tôi sẽ cố gắng sát sao nhất với client cốt lõi của Solana, nhưng dự định sẽ chuyển sang Firedancer ngay khi mã ổn định.
Bảo mật
Diện tích tấn công của runtime Solana được giảm đáng kể, giúp ngăn chặn các cuộc tấn công đệ quy mà chúng ta đã thấy quá nhiều lần. Cụ thể, runtime Solana chỉ cho phép chương trình tự đệ quy, chứ không cho phép gọi chéo chương trình tùy ý có thể tái nhập. Ngoài ra, việc tách biệt trạng thái và mã dẫn đến mã không trạng thái, thường dễ kiểm thử hiệu quả hơn.
Xác minh đơn giản hơn
SVM dựa trên thanh ghi, tập lệnh nhỏ hơn nhiều so với EVM, điều này khiến việc chứng minh thực thi SVM trong ZK trở nên dễ dàng hơn. Đối với optimistic rollup, thiết kế dựa trên thanh ghi cho phép tạo điểm kiểm tra đơn giản hơn.
Lớp thanh toán: Bảo mật và thanh khoản của Ethereum
Giống như các rollup chính hiện nay, Eclipse Mainnet sẽ thanh toán với Ethereum. Cụ thể, điều này nghĩa là cầu nối xác thực của chúng tôi trên Ethereum sẽ được tích hợp trực tiếp vào Eclipse. Các nút Eclipse sẽ kiểm tra cầu nối này để xác định "chuỗi tiêu chuẩn". Cầu nối này sẽ ép buộc việc sắp xếp đúng đắn cho Eclipse.
Điều này cho phép người dùng của chúng tôi thừa hưởng một số thuộc tính bảo mật từ Ethereum. Cầu nối sẽ xác thực tất cả các giao dịch Eclipse, ngăn chặn việc gửi trạng thái không hợp lệ. Ngoài ra, nó sẽ đảm bảo tính sống động cuối cùng và chống kiểm duyệt trong một số trường hợp thất bại. Ngay cả khi trình sắp xếp L2 ngừng hoạt động hoặc bắt đầu kiểm duyệt, người dùng vẫn có thể ép buộc đưa giao dịch của họ vào thông qua cầu nối này.
Nhờ những thuộc tính bảo mật này, các kho lưu trữ hiệu quả và tối ưu thường được gọi là "L2 Ethereum". L2BEAT định nghĩa L2 là "một chuỗi, an toàn hoàn toàn hoặc một phần bắt nguồn từ lớp 1 Ethereum, để người dùng không cần phải tin tưởng vào tính trung thực của các trình xác thực L2 để đảm bảo an toàn tiền của họ."
Việc thanh toán với Ethereum thể hiện tầm quan trọng của tài sản bản địa Ethereum trong nền kinh tế DeFi và NFT trên Eclipse Mainnet. ETH là loại tiền phi tập trung tốt nhất, rõ ràng là lựa chọn hàng đầu của đa số người dùng, do đó chúng tôi cũng sẽ dùng ETH làm token gas. Về lâu dài, việc trừ phí gián tiếp sẽ cho phép người dùng trả bằng bất kỳ token nào họ chọn (ví dụ: USDC). Hiện tại, Eclipse Mainnet không có kế hoạch phát hành token riêng.
Khả năng truy cập dữ liệu: Băng thông và khả năng kiểm chứng của Celestia
Eclipse Mainnet sẽ sử dụng Celestia cho khả năng truy cập dữ liệu (còn gọi là công bố dữ liệu hay xuất bản dữ liệu). Celestia đã là đối tác hệ sinh thái lâu dài của Eclipse.
Mục tiêu thông lượng và phí của Eclipse Mainnet tiếc thay không được hỗ trợ bởi giới hạn băng thông hiện tại của Ethereum. Ngay cả sau EIP-4844 (còn gọi là "Proto-danksharding"), cung cấp khoảng 0,375 MB blobspace cho mỗi khối (giới hạn khoảng 0,75 MB mỗi khối).
-
Đối với giao dịch ERC-20 cơ bản có nén (khoảng 154 byte mỗi giao dịch), điều này tương đương khoảng 213 TPS cho tất cả Rollup.
-
Đối với hoán đổi có nén (khoảng 400 byte mỗi giao dịch), điều này tương đương khoảng 82 TPS cho tất cả các tổng hợp.
Ngược lại, Celestia sẽ ra mắt khối 2 MB vào cuối năm nay. Ngay khi có đủ các nút nhẹ DAS (data availability sampling) đi vào hoạt động và mạng được chứng minh là ổn định, không gian blob dự kiến sẽ tăng lên 8 MB ngay sau khi khởi chạy. Các nút nhẹ DAS phục vụ hai chức năng then chốt:
-
Cho phép người dùng tự xác minh dữ liệu khối Eclipse có sẵn hay không;
-
Góp phần mở rộng an toàn toàn bộ mạng, vì khi càng nhiều nút nhẹ DAS đi vào hoạt động, tầng DA có thể an toàn tăng thông lượng của nó.
Dự kiến Celestia sẽ là tầng DA đầu tiên triển khai DAS trong môi trường sản xuất. Điều này trái ngược với các ủy ban khả năng truy cập dữ liệu truyền thống (DAC), vốn tái giới thiệu giả định trung thực ủy ban mà không có xác minh từ người dùng (tương tự như các blockchain monolithic hiện tại).
Đối với người dùng chuyển tiền từ Ethereum mainnet sang bất kỳ chuỗi nào dùng DA ngoại chuỗi, luôn tồn tại những giả định bảo mật nội tại. Đặc biệt, về mặt kỹ thuật, các trình xác thực Celestia có thể từ chối dữ liệu giao dịch nhưng lại tuyên bố dữ liệu đó có sẵn trên cầu nối Ethereum. Trên thực tế, cơ chế đồng thuận proof-of-stake của Celestia nghĩa là việc giữ lại dữ liệu của chính Celestia là có thể bị phạt, điều này khiến chúng tôi cho rằng rủi ro này không thực tế.
Tổng thể, sự hỗ trợ nút nhẹ DAS từ ngày đầu tiên, thuộc tính bảo mật kinh tế-mã hóa, cùng với thông lượng DA có thể mở rộng cao, khiến Celestia trở thành lựa chọn rõ ràng hiện tại cho Eclipse Mainnet.
Chúng tôi cũng dự định theo dõi tiến triển của Ethereum trong việc mở rộng DA sau EIP-4844. Những nghiên cứu mới đầy hứng khởi không ngừng xuất hiện, có thể cung cấp DA thông lượng cao sớm hơn so với những ý tưởng trước đây (sử dụng bảng băm phân tán nâng cao hơn). Nếu Ethereum cung cấp quy mô lớn hơn cho người dùng của chúng tôi, chúng tôi sẽ đánh giá khả năng chuyển sang DA của Ethereum.
Xác minh: Bằng chứng gian lận ZK của RISC Zero (không cần tuần tự hóa trạng thái trung gian!)
Xác minh của chúng tôi sẽ tương tự như SIMD của Anatoly về bằng chứng gian lận SVM, bản thân nó lại tương tự với nhận định của John Adler rằng việc tuần tự hóa trạng thái tốn kém và có thể tránh được.
Cụ thể, chúng tôi muốn tránh việc tái giới thiệu cây Merkle trong SVM. Chúng tôi đã thử chèn cây Merkle thưa sau mỗi giao dịch trong SVM, nhưng việc cập nhật cây Merkle gây ra tổn thất hiệu suất rõ rệt. Việc không dùng cây Merkle loại bỏ các framework rollup phổ quát hiện có (như OP Stack) làm nền tảng cho rollup SVM, và đòi hỏi một kiến trúc bằng chứng lỗi sáng tạo hơn.
Tóm lại, bằng chứng lỗi cần:
-
Cam kết đầu vào giao dịch,
-
Bản thân giao dịch, và
-
Bằng chứng rằng việc thực thi lại giao dịch tạo ra đầu ra khác với đầu ra được chỉ định trên chuỗi.
Cam kết đầu vào thường được thực hiện bằng cách cung cấp gốc Merkle của cây trạng thái rollup. Chương trình thực thi của chúng tôi sẽ công bố danh sách đầu vào và đầu ra cho mỗi giao dịch (bao gồm băm tài khoản và trạng thái toàn cục liên quan), cùng với chỉ số của giao dịch tạo ra mỗi đầu vào. Giao dịch được công bố trên Celestia, do đó bất kỳ nút đầy đủ nào cũng có thể tự trích xuất tài khoản từ trạng thái của riêng mình, tính toán tài khoản đầu ra, và xác nhận cam kết trên Ethereum là chính xác.
Có thể xảy ra hai loại lỗi chính:
-
Đầu ra sai — Trong trường hợp này, người xác thực cung cấp trên chuỗi bằng chứng zero-knowledge về đầu ra đúng của việc thực thi SVM. Chúng tôi dùng RISC Zero để tạo bằng chứng zero-knowledge cho việc thực thi SVM, là sự kế thừa từ việc chứng minh thực thi bytecode BPF trước đó. Điều này cho phép hợp đồng thanh toán của chúng tôi đảm bảo tính đúng đắn mà không cần tự chạy các giao dịch đó trên chuỗi.
-
Đầu vào sai — Trong trường hợp này, người xác thực đăng trên chuỗi trỏ đến dữ liệu lịch sử, cho thấy trạng thái đầu vào không khớp với tuyên bố. Sử dụng cầu nối Quantum Gravity Bridge của Celestia, hợp đồng thanh toán của chúng tôi đảm bảo dữ liệu lịch sử này thực sự chứng minh được gian lận.
Chúng tôi đang đứng trên vai những người khổng lồ. Các rollup ngày nay đã thúc đẩy nghiên cứu của toàn ngành và cung cấp mức phí thấp hơn cho người dùng Ethereum so với L1.
Tuy nhiên, chúng chưa tận dụng đầy đủ các công nghệ mới nhất cần thiết để đạt quy mô lớn. Những tiến bộ đáng kinh ngạc gần đây đã loại bỏ nhu cầu phải đánh đổi như các rollup đầu tiên, thực tế khiến chúng trở nên yếu thế hơn:
-
Máy ảo hiệu suất cao, thực thi song song (ví dụ: SVM);
-
Mở rộng DA với hỗ trợ nút nhẹ DAS (ví dụ: Celestia);
-
Tiến bộ hạ tầng xác minh khiến nó trở nên thực tế ở mọi nơi (ví dụ: RISC Zero);
-
Tăng khả năng di động mã (ví dụ: Neon và Solang) và người dùng (ví dụ: MetaMask Snaps) xuyên suốt hệ sinh thái
Chúng tôi có thể học hỏi từ những hạn chế mà các chuỗi khác phải đối mặt, rồi chọn lọc những phần tốt nhất để mở rộng lâu dài.
Chúng tôi thường nghe nói về viễn cảnh tương lai với 1 triệu rollup riêng cho từng ứng dụng.
Tùy chỉnh cấp đồng thuận có thể rất có giá trị đối với một số ứng dụng (ví dụ: dYdX v4), và chúng tôi rất vui khi hỗ trợ các đội ngũ triển khai rollup riêng cho ứng dụng.
Tuy nhiên, những trường hợp như vậy cực kỳ hiếm. Đó là lý do vì sao phần lớn các rollup mới vẫn chỉ là bản sao EVM thông thường. Vấn đề của nhà phát triển sẽ không được giải quyết bằng cách phân mảnh UX trên nhiều chuỗi hơn. Ngày nay, trường hợp sử dụng chính cho hàng triệu chuỗi dường như thường chỉ là khởi chạy thêm nhiều token. Đối với đa số trường hợp sử dụng, nhu cầu tùy chỉnh toàn bộ stack công nghệ hoàn chỉnh không tồn tại.
Ngay cả khi nhu cầu thực sự tồn tại, hạ tầng cần thiết để hỗ trợ nhiều chuỗi ứng dụng có UX cạnh tranh cũng phải mất nhiều năm nữa mới sẵn sàng (nếu có thể đạt được mức độ tương đương). Optimism Superchain (OP Stack), zkSync Hyperchains (ZK Stack), Arbitrum Orbit chains đều có tầm nhìn nhiều chuỗi với cơ sở hạ tầng chia sẻ. Mục đích là để cung cấp trải nghiệm UX trơn tru hơn cho thao tác giữa các chuỗi trong cùng hệ sinh thái (ví dụ: giữa hai chuỗi trong Superchain), chứ không phải giữa các chuỗi hoàn toàn tách biệt (ví dụ: giữa Ethereum và Solana).
Tuy nhiên, các kế hoạch hiện tại (nếu có) còn rất xa mới có thể cạnh tranh với một máy trạng thái chia sẻ đơn lẻ. Hơn nữa, chúng không giải quyết được vấn đề tương tác xuyên hệ sinh thái (ví dụ: từ Superchain sang Hyperchain). Xây dựng mô-đun không nên đồng nghĩa với việc xây dựng các hòn đảo biệt lập.
Người dùng duy trì tài khoản trên nhiều chuỗi sẽ phức tạp hơn. Việc liên tục chuyển chuỗi và lo lắng về token gas cần thiết là trải nghiệm tồi tệ hơn. Việc phụ thuộc vào các nhà cung cấp hạ tầng để vận hành và duy trì quá nhiều chuỗi cũng phức tạp và tốn kém hơn.
Chúng tôi luôn trân trọng sự đơn giản trong tầm nhìn của Solana. Một máy trạng thái chia sẻ được tối ưu hóa cao, có quy mô hỗ trợ hầu hết các trường hợp sử dụng có giá trị. Điều này thường bị coi là không tương thích với lộ trình tập trung vào rollup, nhưng thực tế thì không phải vậy. Chúng tôi muốn kết hợp ưu điểm của cả hai.
Sự hiểu lầm này xuất phát từ việc các rollup ngày nay phần lớn chạy EVM đơn luồng nguyên bản, hầu như không thay đổi gì để tận dụng hiệu ứng mạng ban đầu. Do đó, chúng ta thường thấy “không gian khối dành riêng” được trích dẫn như lý do triển khai rollup riêng cho ứng dụng. Ứng dụng khác trên chuỗi bạn không nên bị tăng giá chỉ vì một lần đúc NFT điên rồ, nhưng câu trả lời không phải là làm riêng một chuỗi. Bạn đã thực hiện những đánh đổi đau đớn và không cần thiết (phức tạp, chi phí, UX tồi tệ hơn, thanh khoản phân mảnh, v.v.). Giải pháp tốt nhất là rõ ràng — chỉ cần dùng máy ảo song song có thị trường phí gốc cho các điểm nóng trạng thái. Chính xác là điều SVM mang lại.
Ethereum là trung tâm tri thức, xã hội và kinh tế của tiền mã hóa. Điểm yếu chí tử của nó luôn là khả năng mở rộng. Việc mở rộng khả năng truy cập dữ liệu vẫn đang được tiến hành, trong khi các môi trường thực thi L2 hiện tại không thể cạnh tranh với các đổi mới mới hơn như SVM. Chúng tôi lo ngại rằng nếu tiếp tục trạng thái hiện tại, hệ sinh thái Ethereum sẽ bị bất ngờ khi bất kỳ hoạt động nào gia tăng mạnh mẽ. EVM đơn luồng và khả năng truy cập dữ liệu bị giới hạn sẽ nhanh chóng dẫn đến việc tái hiện lại mức phí cao, chỉ là lần này xảy ra trên rollup.
Chúng tôi cho rằng Eclipse Mainnet là giải pháp hiển nhiên: kết hợp hiệu suất của Solana với tính bảo mật, khả năng kiểm chứng và hiệu ứng mạng của lộ trình tập trung vào rollup.
Kết luận
Điều tuyệt vời ở Ethereum là nó không ngừng đổi mới. Lộ trình tập trung vào rollup là minh chứng điển hình, trao quyền thực thi và đổi mới cho thị trường tự do. Các L2 có khả năng tuyệt vời tận dụng hiệu ứng mạng và đảm bảo thanh toán của Ethereum, đồng thời thử nghiệm các môi trường thực thi mới tốt nhất. Eclipse Mainnet là hiện thực tự nhiên của tầm nhìn này.
Nếu một ngày nào đó xuất hiện một lớp thực thi hiệu suất cao hơn, chúng tôi sẽ rất háo hức thấy nó được triển khai như một L2 Ethereum cạnh tranh. Trước lúc đó, SVM vẫn là tiêu chuẩn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@EclipseFND
