Giới thiệu:

Bài viết này cung cấp một giới thiệu nhìn về phía trước về một mô hình thiết kế hạ tầng Web3 không thông thường: Mô hình Đồng thuận Dựa trên Lưu trữ (SCP). Mô hình thiết kế này có sự khác biệt đáng kể so với các giải pháp blockchain modul chính thống như Ethereum Rollups về lý thuyết. Tuy nhiên, nó thể hiện tính khả thi cao về sự đơn giản trong triển khai và tích hợp với các nền tảng Web2. SCP không có ý định hạn chế bản thân mình vào một con đường hẹp của việc hiện thực như Rollups. Thay vào đó, nó nhắm vào việc áp dụng một khung cảnh rộng lớn và mở hơn để hợp nhất các nền tảng Web2 với hạ tầng Web3. Cách tiếp cận này có thể được xem là rất sáng tạo và đổi mới.

Hãy tưởng tượng một giải pháp mở rộng blockchain công cộng với những đặc điểm sau:

• Nó có tốc độ tương đương với các ứng dụng hoặc sàn giao dịch Web2 truyền thống, vượt xa bất kỳ blockchain công cộng nào, Layer 2 (L2), rollups, sidechains, v.v.

• Không có phí gas, và chi phí sử dụng gần như bằng không.

• An ninh tài chính cao, vượt trội hơn các cơ sở trung tâm như sàn giao dịch, kém hơn Rollups nhưng lớn hơn hoặc bằng sidechains.

• Một trải nghiệm người dùng giống hệt như Web2, mà không cần bất kỳ kiến thức nào về khóa công cộng và riêng tư của blockchain, ví, cơ sở hạ tầng, v.v.

Một giải pháp như vậy thực sự rất hấp dẫn: một mặt, nó đã đạt đến đỉnh cao về mặt mở rộng; mặt khác, nó tạo nền tảng vững chắc cho việc áp dụng hàng loạt của Web3, về cơ bản là kết nối khoảng cách giữa trải nghiệm người dùng của Web2 và Web3. Tuy nhiên, có vẻ như chúng ta có rất ít giải pháp toàn diện như thế này, vì thảo luận và thực hành chính thống thực sự quá ít.

Chúng tôi sử dụng chủ đề phổ biến về việc mở rộng như một sự giới thiệu ở trên, nhưng SCP không giới hạn ở các trường hợp sử dụng mở rộng. Sự truyền cảm hứng thiết kế thực sự đến từ các giải pháp mở rộng và các cuộc thảo luận cộng đồng của các chuỗi khối công khai như Bitcoin và Ethereum. Tầm nhìn và ứng dụng thực tế của nó là xây dựng một thế hệ mới của cơ sở hạ tầng không đáng tin cậy, thậm chí là các nền tảng tính toán không dựa trên cấu trúc chuỗi khối.

Các thành phần cơ bản và nguyên lý hoạt động của SCP

Nói chung, SCP, giống như “bộ khối blockchain” được đề cập bởi cộng đồng Ethereum và Celestia, có các mô-đun khác nhau như một lớp sẵn có dữ liệu, lớp thực thi, lớp đồng thuận và lớp thanh toán.

• Data Availability Layer: Được xử lý bởi một blockchain công cộng được công nhận rộng rãi và được thử nghiệm tốt, hoặc các cơ sở lưu trữ phục vụ như lớp sẵn có dữ liệu, như Ethereum, Arweave, Celestia, v.v.

• Lớp Thực thi: Một máy chủ được sử dụng để nhận giao dịch của người dùng và thực thi chúng, đồng thời gửi dữ liệu giao dịch đã ký theo lô đến lớp DA, tương tự như sequencers trong Rollups. Tuy nhiên, lớp thực thi không nhất thiết cần có cấu trúc chuỗi kiểu blockchain; nó có thể hoàn toàn là một hệ thống cơ sở dữ liệu + tính toán Web2, nhưng toàn bộ hệ thống tính toán phải là mã nguồn mở, với tính minh bạch.

• Lớp Đồng thuận: Bao gồm một nhóm các nút kéo dữ liệu được gửi đến lớp DA bởi lớp thực thi và sử dụng cùng thuật toán với lớp thực thi để xử lý dữ liệu này, xác nhận xem đầu ra của lớp thực thi có đúng không và có thể phục vụ như một dự phòng phục hồi sau thảm họa cho lớp thực thi. Người dùng cũng có thể đọc dữ liệu trả về từ các nút lớp đồng thuận để đảm bảo rằng không có hành vi gian lận nào trong lớp thực thi.

• Lớp Thanh toán: Bao gồm một nhóm các nút và hợp đồng hoặc địa chỉ trên các chuỗi khác, chịu trách nhiệm xử lý việc gửi tiền của người dùng vào SCP, hoặc rút tiền từ SCP, hơi tương tự như hoạt động của cầu nối qua chuỗi. Các nút lớp thanh toán kiểm soát chức năng rút tiền của địa chỉ gửi tiền thông qua hợp đồng multisig hoặc địa chỉ dựa trên TSS. Đối với gửi tiền, người dùng chuyển tài sản vào một địa chỉ được chỉ định trên chuỗi của họ; đối với rút tiền, họ gửi yêu cầu, và sau khi các nút lớp thanh toán đọc dữ liệu, họ phát hành tài sản thông qua multisig hoặc TSS. Mức độ bảo mật của lớp thanh toán phụ thuộc vào cơ chế qua chuỗi được sử dụng.

Khung khổ SCP Thực hành

Chúng ta có thể hiểu Paradigm SCP thông qua khuôn khổ sau. Một sản phẩm đáp ứng khuôn khổ SCP có thể có các tính năng chính như gửi tiền, chuyển khoản, rút tiền, đổi, v.v., và có thể được mở rộng thêm. Dưới đây là một biểu đồ mô phỏng về một sản phẩm như vậy:

• Lớp DA của dự án này sử dụng cơ sở lưu trữ cố định Arweave, được đại diện bởi hình tròn lớn trong biểu đồ.
• Người phối hợp, hoặc tầng thực thi, là nơi người dùng gửi giao dịch của họ. Người phối hợp thực hiện các phép tính, hiển thị kết quả, sau đó gom nhóm dữ liệu đầu vào ban đầu từ người dùng và gửi nó đến tầng DA.
• Detector rút dữ liệu giao dịch gốc được gửi bởi Coordinator từ Arweave, và sử dụng cùng thuật toán như Coordinator, xác minh dữ liệu và kết quả. Khách hàng của Detector cũng là mã nguồn mở, cho phép bất kỳ ai chạy nó.
• The Watchmen, một nhóm của các Detectors, quản lý hệ thống chữ ký đa chữ ký của hệ thống rút tiền. Họ xác minh và ủy quyền các yêu cầu rút tiền dựa trên dữ liệu giao dịch. Ngoài ra, các Watchmen chịu trách nhiệm ký các đề xuất.

Chúng ta có thể thấy rằng sự đồng thuận đạt được bởi toàn bộ hệ thống là hoàn toàn ngoài chuỗi, đó là cốt lõi của mô hình đồng thuận lưu trữ. Nó từ bỏ hệ thống đồng thuận nút điển hình của blockchain, giải phóng lớp thực thi khỏi quá trình xác nhận và giao tiếp đồng thuận nặng nề. Điều này cho phép nó hoạt động hiệu quả như một máy chủ duy nhất, do đó đạt được TPS gần như không giới hạn và hiệu quả chi phí. Khía cạnh này rất giống với Rollups, nhưng SCP (Storage Consensus Paradigm) đi theo một con đường khác với Rollups. SCP cố gắng chuyển đổi từ trường hợp sử dụng dành riêng cho quy mô sang chế độ chuyển tiếp mới từ Web2 sang Web3. Điều phối viên nói trên là một máy chủ, nhưng điều này không có nghĩa là Điều phối viên có thể hành động tùy ý. Tương tự như trình sắp xếp chuỗi trong Rollups, sau khi gửi hàng loạt dữ liệu gốc từ người dùng trên Arweave, bất kỳ ai cũng có thể chạy chương trình Detector để xác minh và so sánh nó với trạng thái do Điều phối viên trả về. Theo một số cách, điều này gần giống với cách tiếp cận của các ứng dụng kiểu chữ khắc. Trong kiến trúc này, một máy chủ hoặc cơ sở dữ liệu tập trung không đặt ra một thách thức cơ bản. Đây là một điểm khác của mô hình SCP: nó tách rời các khái niệm "tập trung" và "thực thể duy nhất" - trong một hệ thống không tin cậy, có thể có các thành phần tập trung, thậm chí là một thành phần cốt lõi, mà không ảnh hưởng đến sự tin cậy tổng thể của hệ thống.

Chúng ta có thể hét lên khẩu hiệu này: "Thế hệ tiếp theo của cơ sở hạ tầng không tin cậy không nhất thiết phải dựa vào các giao thức đồng thuận, nhưng nó phải là một hệ thống nguồn mở với mạng nút ngang hàng (P2P)." Mục đích ban đầu của việc phát minh và sử dụng blockchain là để đạt được sự phân cấp, tính nhất quán của sổ cái, tính bất biến và khả năng truy xuất nguồn gốc, như đã nêu rõ trong whitepaper Bitcoin. Tuy nhiên, sau Ethereum, cho dù đó là các giải pháp mở rộng của chuỗi công khai cũ, Rollups hay blockchain mô-đun, có một tư duy cố định: những gì chúng ta đang tạo phải là một blockchain (bao gồm các giao thức đồng thuận của các nút) hoặc một cái gì đó như Rollup (dường như là một chuỗi với cấu trúc dữ liệu blockchain, nhưng không có trao đổi thông điệp đồng thuận trực tiếp giữa các nút). Bây giờ, theo khuôn khổ dựa trên SCP (Giao thức đồng thuận Stellar), rõ ràng là ngay cả khi không phải là một blockchain, vẫn có thể đạt được sự phân cấp, tính nhất quán của sổ cái, tính bất biến và khả năng truy xuất nguồn gốc, miễn là có nhiều chi tiết triển khai rõ ràng hơn.

Lớp Thực Thi

Lớp thực thi rất quan trọng trong toàn bộ hệ thống vì nó thực hiện các quy trình tính toán của hệ thống và xác định loại ứng dụng có thể chạy trên hệ thống.

Vô số khả năng trong môi trường thực thi

Lý thuyết, môi trường thực thi trong lớp thực thi có thể có bất kỳ hình thức nào, với vô số khả năng, phụ thuộc vào cách mà các nhà phát triển dự án định vị dự án của họ:

1. Sàn giao dịch. Sử dụng SCP, người ta có thể xây dựng một sàn giao dịch công khai, minh bạch với tốc độ giao dịch cao mỗi giây (TPS), kết hợp các tính năng nhanh chóng, không phí của một sàn Giao dịch Tập trung (CEX) và sự phi tập trung của một Sàn Giao dịch Phi tập trung (DEX). Ở đây, sự phân biệt giữa CEX và DEX trở nên mờ nhạt.

2. Mạng thanh toán. Tương tự như Alipay, PayPal, vv.

3. Máy ảo/Blockchain hỗ trợ chương trình/hợp đồng có thể tải được. Bất kỳ nhà phát triển nào cũng có thể triển khai bất kỳ ứng dụng nào trên đó, chia sẻ tất cả dữ liệu người dùng với các chương trình khác và hoạt động theo hướng dẫn của người dùng.

Mẫu thiết kế của SCP, hỗ trợ bất kỳ môi trường thực thi nào, có những lợi thế độc đáo của mình: không cần phải phụ thuộc vào các thành phần có gánh nặng lịch sử, đặc biệt là các khái niệm như “trừu tượng tài khoản” độc đáo của cộng đồng Ethereum. Đối với SCP, khái niệm về trừu tượng tài khoản là không cần thiết theo bản chất. Trong kiến trúc SCP, không có khái niệm về trừu tượng tài khoản - bạn có thể tự do áp dụng các tài khoản tiêu chuẩn Web2 và tài khoản blockchain, v.v. Từ góc độ này, nhiều trường hợp sử dụng Web2 đã chín muồi không cần phải suy nghĩ lại và xây dựng lại để áp dụng trực tiếp cho SCP. Khía cạnh này có thể là nơi mà SCP có lợi thế hơn so với Rollups.

Sự minh bạch và không đối xứng

Hệ thống tài khoản đã được đề cập ở trên, và độc giả sắc bén có thể đã nhận ra rằng trong khi SCP (Giao thức đồng thuận Stellar) có thể sử dụng hệ thống tài khoản Web2, việc sử dụng nó như vậy dường như gặp vấn đề. Điều này bởi vì toàn bộ hệ thống là hoàn toàn minh bạch! Việc sử dụng mô hình tương tác người dùng-máy chủ trực tiếp từ Web2 dẫn đến các vấn đề bảo mật nghiêm trọng, làm cho hệ thống hoàn toàn không an toàn. Hãy xem xét cách mà mô hình máy chủ-người dùng truyền thống hoạt động:

1. Đăng ký tài khoản : Người dùng nhập tên người dùng và mật khẩu trên trang đăng ký ứng dụng. Để bảo vệ mật khẩu của người dùng, máy chủ xử lý thông qua hàm băm khi nhận được. Để tăng độ phức tạp của hàm băm và chống lại các cuộc tấn công bảng màu của cầu vồng, một chuỗi được tạo ngẫu nhiên (được gọi là “muối”) thường được thêm vào mỗi mật khẩu của người dùng trước khi băm. Tên người dùng, muối và hàm băm được lưu trữ dưới dạng văn bản thuần trong cơ sở dữ liệu của nhà cung cấp dịch vụ và không được công khai. Tuy nhiên, việc sử dụng muối và xử lý an toàn vẫn cần thiết để ngăn chặn các mối đe dọa từ bên trong và các cuộc tấn công.

1. Đăng nhập Người dùng: Người dùng nhập tên người dùng và mật khẩu vào mẫu đăng nhập. Hệ thống so sánh băm mật khẩu được xử lý với băm được lưu trữ trong cơ sở dữ liệu. Nếu hai băm khớp nhau, điều đó cho thấy người dùng đã cung cấp mật khẩu chính xác và quy trình đăng nhập tiếp tục.

2. Xác thực Hoạt động : Sau khi xác minh đăng nhập thành công, hệ thống tạo một phiên cho người dùng. Thông tin phiên thường được lưu trữ trên máy chủ, và máy chủ gửi một bộ nhận dạng (như một cookie hoặc mã thông báo) đến trình duyệt hoặc ứng dụng của người dùng. Trong các hoạt động tiếp theo, người dùng không cần phải nhập tên người dùng và mật khẩu lặp đi lặp lại: trình duyệt hoặc ứng dụng lưu trữ bộ nhận dạng cookie và bao gồm nó trong mọi yêu cầu, cho biết rằng họ có sự cho phép của máy chủ liên quan đến cookie.

Hãy xem xét hệ thống tương tác người dùng blockchain Web3 điển hình:

1. Đăng ký tài khoản: Trong thực tế, không có quy trình đăng ký tài khoản, cũng như hệ thống tên người dùng-mật khẩu. Tài khoản (địa chỉ) không cần phải đăng ký; chúng tồn tại theo bản chất, và ai kiểm soát khóa riêng tư thì kiểm soát tài khoản. Khóa riêng tư được tạo ngẫu nhiên tại địa phương bởi ví tiền và không liên quan đến quy trình trực tuyến nào.

2. Đăng nhập người dùng: Sử dụng blockchain không yêu cầu đăng nhập. Hầu hết các ứng dụng phi tập trung không có quá trình đăng nhập mà kết nối với ví thay vào đó. Một số ứng dụng phi tập trung, sau khi kết nối với ví, có thể yêu cầu người dùng ký kết để đảm bảo họ thực sự nắm giữ khóa riêng, thay vì chỉ đã gửi địa chỉ ví tới giao diện trước.

3. Xác thực hoạt động: Người dùng trực tiếp gửi dữ liệu đã ký cho các nút. Sau khi xác thực, các nút phát sóng giao dịch đến toàn bộ mạng lưới blockchain. Khi hoạt động được xác nhận bởi sự đồng thuận của mạng lưới blockchain, nó được hoàn tất.

Sự khác biệt giữa hai chế độ này được gây ra bởi các yếu tố đối xứng và không đối xứng. Trong kiến trúc máy chủ-người dùng, cả hai bên đều giữ cùng một bí mật. Trong kiến trúc blockchain-người dùng, chỉ người dùng giữ bí mật. Mặc dù lớp thực thi của SCP (Nền tảng Hợp đồng Thông minh) có thể không phải là một blockchain, tất cả dữ liệu cần được đồng bộ hóa với một lớp DA (Khả năng Truy cập Dữ liệu) công khai. Do đó, các phương pháp xác minh đăng nhập và hoạt động của SCP phải là không đối xứng. Tuy nhiên, để tránh những hành động rườm rà như quản lý khóa riêng và sử dụng ví điện tử, có thể làm chậm quá trình áp dụng rộng rãi do trải nghiệm người dùng kém, có một nhu cầu mạnh mẽ cho việc đăng nhập bằng ID-mật khẩu truyền thống hoặc OAuth từ bên thứ ba trong các ứng dụng được xây dựng trên SCP. Vậy, làm thế nào để kết hợp cả hai? Do tính không đối xứng của mật mã và chứng minh không biết, tôi tưởng tượng ra hai giải pháp khả thi:

• Nếu hệ thống ID-mật khẩu được yêu cầu, mô-đun lưu trữ mật khẩu có thể được loại bỏ khỏi SC, khiến cho nó trở nên vô hình đối với người khác. Bên trong, lớp thực thi SCP vẫn sử dụng tài khoản khóa công khai-tư của blockchain và logic hoạt động, mà không cần đăng ký hoặc đăng nhập. ID của người dùng thực sự tương ứng với một khóa riêng tư. Khóa riêng tư này, tất nhiên, không nên được lưu trữ bởi bên dự án. Một giải pháp khả thi là sử dụng 2-3 MPC (Tính toán Đa bên) để giải quyết vấn đề lưu trữ tập trung mà không làm nặng người dùng với việc sử dụng một khóa riêng tư.
• Khi phụ thuộc vào đăng nhập OAuth, JWT (JSON Web Token) có thể được sử dụng như một phương tiện xác thực danh tính. Phương pháp này có chút tập trung hơn so với phương pháp trên, vì nó dựa vào dịch vụ đăng nhập bên thứ ba được cung cấp bởi những ông lớn Web2 để xác minh danh tính.
• Lần đầu tiên khi sử dụng đăng nhập bên thứ ba, các trường JWT đại diện cho người dùng và nhà cung cấp dịch vụ được đăng ký trong hệ thống. Trong các hoạt động người dùng tiếp theo, lệnh hoạt động được xem như đầu vào công khai, trong khi JWT như một nhân chứng bí mật, sử dụng ZKP (Zero-Knowledge Proof) để xác minh từng giao dịch của người dùng.
• Mỗi JWT có giới hạn thời gian hết hạn, và người dùng sẽ yêu cầu một JWT mới lần sau khi họ đăng nhập, vì vậy không cần lưu trữ vĩnh viễn. Ngoài ra, hệ thống này phụ thuộc vào JWK (JSON Web Key), mà có thể được hiểu như là khóa công khai được các gigant cung cấp để xác minh JWK. Cách JWK được nhập vào hệ thống theo cách phân tán và phương pháp xoay khóa riêng cho tương lai cũng đáng khám phá.

Bất kể phương pháp nào được sử dụng, cả hai đều tốn kém hơn về mặt phát triển và vận hành so với các phương pháp truyền thống, nhưng đây là một giá cả cần phải trả cho sự phân quyền. Tất nhiên, nếu dự án không coi phân quyền cực độ là cần thiết, hoặc có các cột mốc khác nhau ở các giai đoạn phát triển khác nhau, có thể tiếp tục mà không cần những thiết kế này, vì phân quyền không phải là một vấn đề đen trắng mà tồn tại trong một khu vực xám.

Vấn đề quyền riêng tư

Những vấn đề về tính minh bạch được đề cập ở trên không chỉ ảnh hưởng đến mô hình tương tác người dùng mà còn ảnh hưởng đến dữ liệu người dùng. Dữ liệu người dùng được tiếp xúc trực tiếp. Mặc dù điều này không phải là một vấn đề trong blockchain, nhưng nó là không chấp nhận được trong một số ứng dụng. Do đó, các nhà phát triển cũng có thể xây dựng các hệ thống giao dịch riêng tư.

Phí

Cách mà lớp thực thi tính phí là một điểm khác đáng quan tâm. Việc gửi dữ liệu đến lớp Data Availability (DA) cũng gây ra chi phí, bao gồm hoạt động của các máy chủ riêng của nó. Mục đích chính của việc tính phí gas trong các chuỗi khối truyền thống là để ngăn ngừa người dùng gửi rác mạng với nhiều giao dịch trùng lặp, với việc sắp xếp giao dịch dựa trên phí gas là phụ. Trong Web2, những lo lắng tương tự không tồn tại, chỉ có các khái niệm cơ bản như lũ lụt và tấn công DDoS. Lớp thực thi có thể tùy chỉnh các chiến lược tính phí khác nhau, như hoàn toàn miễn phí hoặc tính phí một phần, hoặc thu lợi từ các hoạt động khác như Giá trị có thể khai thác tối đa (MEV), mà đã rất chín chắn trong sequencers và các hoạt động thị trường.

Không đáng tin cậy Resistance

Lớp thực hiện không có khả năng chống kiểm duyệt và lý thuyết có thể từ chối giao dịch của người dùng một cách vô thời hạn. Trong Rollups, khả năng chống kiểm duyệt có thể được đảm bảo bằng chức năng tổng hợp bắt buộc của hợp đồng L1, trong khi các sidechains hoặc chuỗi công cộng là các mạng blockchain phân tán hoàn chỉnh, làm cho việc kiểm duyệt trở nên khó khăn. Hiện tại, chưa có giải pháp rõ ràng để giải quyết vấn đề khả năng chống kiểm duyệt, đó là một vấn đề trong mô hình SCP.

Consensus Layer

Lớp này bao gồm các nút được kết nối lỏng lẻo không chủ động tạo thành mạng, vì vậy nó không hoàn toàn là một lớp đồng thuận, mà chỉ xác nhận trạng thái hiện tại của lớp thực thi với thế giới bên ngoài (chẳng hạn như người dùng). Ví dụ: nếu bạn nghi ngờ trạng thái hoạt động của các nút này, bạn có thể tải xuống ứng dụng khách phát hiện của chúng, chạy cùng mã chương trình với điều phối viên. Tuy nhiên, tương tự như Rollups, vì dữ liệu được gửi theo lô, trạng thái được trả về bởi lớp thực thi cho người dùng luôn cập nhật hơn so với trên lớp DA. Điều này liên quan đến vấn đề xác nhận trước: lớp thực thi cung cấp cho người dùng xác nhận trước, kết quả cuối cùng mềm, vì chúng chưa được gửi đến lớp DA; trong khi lớp đồng thuận cung cấp tính cuối cùng khó khăn. Người dùng có thể không đặc biệt quan tâm đến điều này, nhưng đối với các ứng dụng như cầu nối chuỗi chéo, tính cuối cùng cứng phải được tuân thủ. Ví dụ: hệ thống gửi và rút tiền của các sàn giao dịch không tin tưởng dữ liệu được phát ngoài chuỗi bởi các trình tự Rollup; họ chờ dữ liệu này có trên Ethereum trước khi chấp nhận. Bên cạnh việc xác nhận kết quả, lớp đồng thuận cũng đóng một vai trò quan trọng như một sự dự phòng thảm họa cho lớp thực thi. Nếu lớp thực thi ngừng hoạt động vĩnh viễn hoặc hoạt động độc hại, về mặt lý thuyết, bất kỳ lớp đồng thuận nào cũng có thể tiếp quản công việc của lớp thực thi và chấp nhận các yêu cầu của người dùng. Nếu tình huống nghiêm trọng như vậy xảy ra, cộng đồng nên chọn các nút ổn định và đáng tin cậy làm máy chủ của lớp thực thi.

Tầng giải quyết

Vì SCP không phải là Rollup, nó không thể đạt được việc rút tiền không đáng tin cậy như lớp giải quyết rút tiền của Rollup, hoàn toàn dựa trên mật mã và mã hợp đồng thông minh mà không cần can thiệp thủ công. Cấp độ bảo mật của cầu nối qua chuỗi của SCP tương tự như cầu nối qua chuỗi hoặc cầu nối bên thứ ba, phụ thuộc vào các quản lý chữ ký đa chữ ký được ủy quyền để phát hành tài sản, được biết đến với chế độ chứng kiến.

Làm cho cầu chứng kiến càng phân quyền càng tốt là một chủ đề nghiên cứu của nhiều cầu chuyển chuỗi. Do hạn chế về không gian, điều này sẽ không được trình bày ở đây. Một nền tảng SCP được thiết kế tốt trong thực tế cũng cần phải có các đối tác chữ ký đa bên phân quyền đáng tin cậy. Một số người có thể hỏi tại sao SCP không sử dụng một chuỗi với hợp đồng thông minh như lớp DA? Điều này sẽ cho phép các lớp thanh toán không đáng tin cậy dựa trên hợp đồng. Trong dài hạn, vượt qua một số khó khăn kỹ thuật, nếu lớp DA được đặt trên Ethereum hoặc các lớp DA hỗ trợ hợp đồng khác và các hợp đồng xác minh tương ứng có thể được xây dựng, SCP cũng có thể đạt được cùng mức độ bảo mật thanh toán như Rollup, mà không cần đến chữ ký đa bên.

Trong thực tế, điều này có thể không phải là lựa chọn tốt nhất:

1. Ethereum không được thiết kế đặc biệt cho việc lưu trữ dữ liệu, và so với các chuỗi khối dành riêng cho việc lưu trữ dữ liệu, nó khá đắt đỏ. Đối với mô hình SCP, chi phí lưu trữ đủ thấp hoặc cố định là rất quan trọng. Chỉ khi đó nó mới có thể hỗ trợ lưu lượng Web2.

2. Việc phát triển hệ thống chứng minh rất khó khăn vì trong SCP, người ta có thể mô phỏng không chỉ EVM (Máy ảo Ethereum) mà còn thực hiện bất kỳ logic nào. Xét đến tình trạng hiện tại của các dự án như Optimism, nơi các bằng chứng gian lận của họ vẫn chưa được ra mắt, và sự phức tạp trong việc phát triển zkEVM (Máy ảo Ethereum không thông báo), người ta có thể tưởng tượng sự khó khăn vô cùng lớn trong việc triển khai các hệ thống chứng minh khác nhau trên Ethereum.

Do đó, giải pháp Rollup chỉ thực sự khả thi hơn trong các trường hợp cụ thể. Nếu bạn dự định triển khai một hệ thống rộng hơn, linh hoạt hơn, di chuyển khỏi khung EVM để tích hợp nhiều tính năng Web2 hơn, thì phương pháp Ethereum Rollup không phù hợp. SCP không chỉ là kế hoạch mở rộng cho một số blockchain công cộng cụ thể, mà còn là một kiến trúc nền tảng tính toán Web3 lớn hơn. Do đó, rõ ràng không cần phải tuân theo phương pháp Layer2 của Ethereum.

Một minh họa so sánh SCP với các mô hình khác

Miễn trừ trách nhiệm：

1. Bài viết này được in lại từ [ GeekWeb3]. Tất cả bản quyền thuộc về tác giả gốc [Máy năm, Web3 của những người đam mê công nghệ]. 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 Cổng Họcđội ngũ, và họ sẽ xử lý nhanh chóng.
2. Miễn trừ trách nhiệm về trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không cấu thành 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 nêu rõ, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.