Giải thích SCP: Mô hình cơ sở hạ tầng không tin cậy bên ngoài công thức tổng hợp

Tác giả: Wuyue, Geek Web3

**Giới thiệu:**Bài viết này sẽ giới thiệu một mô hình thiết kế cơ sở hạ tầng Web3 có vẻ hơi maverick - **Mô hình đồng thuận lưu trữ SCP (Mô hình đồng thuận dựa trên lưu trữ) **, mặc dù mô hình thiết kế sản phẩm này về mặt lý thuyết khá khác so với các giải pháp Blockchain mô-đun chính thống như Ethereum Rollup, nhưng ** trong sự đơn giản của việc hạ cánh và khó khăn khi kết nối với nền tảng Web2, tính khả thi là rất cao ** Bởi vì anh ấy không có ý định giới hạn bản thân trong một con đường triển khai hẹp như Rollup ngay từ đầu, anh ấy muốn sử dụng một khuôn khổ rộng hơn và cởi mở hơn để ** hợp nhất nền tảng Web2 với cơ sở hạ tầng Web3 **, có thể nói là một cách tiếp cận mở não và giàu trí tưởng tượng. Giới thiệu: Bài viết này sẽ giới thiệu một cách tiềm năng một mô hình thiết kế cơ sở hạ tầng Web3 hơi maverick - Mô hình đồng thuận lưu trữ (SCP) Mặc dù mô hình thiết kế sản phẩm này về mặt lý thuyết khá khác biệt so với các giải pháp Blockchain mô-đun chính thống như Ethereum Rollup, nhưng nó rất khả thi về mặt đơn giản trong việc triển khai và khó kết nối với các nền tảng Web2, bởi vì anh không có ý định giới hạn bản thân trong một con đường triển khai hẹp như Rollup ngay từ đầu, và muốn tích hợp nền tảng Web2 và các cơ sở Web3 với một khuôn khổ rộng hơn và cởi mở hơn, có thể nói là một cách tiếp cận mở não và giàu trí tưởng tượng.

Thân bài: Hãy tưởng tượng một sơ đồ mở rộng quy mô chuỗi công khai với các đặ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ỳ chuỗi công khai nào, L2, rollup, sidechain, v.v.
• Không có phí xăng, và chi phí sử dụng gần như bằng không.
• Tính bảo mật cao của các quỹ, vượt xa các cơ sở tập trung như sàn giao dịch, kém hơn Rollup nhưng lớn hơn hoặc bằng Sidechain.
• Trải nghiệm người dùng tương tự như Web2, không có bất kỳ kiến thức nào về khóa, ví, cơ sở hạ tầng công khai và riêng tư của Blockchain, v.v.

Giải pháp này thực sự rất thú vị: một mặt, về cơ bản, nó đã đạt được kết quả cuối cùng trong việc mở rộng quy mô, mặt khác, nó đã đặt nền tảng vững chắc cho việc áp dụng hàng loạt Web3, về cơ bản loại bỏ khoảng cách giữa trải nghiệm Web2 và Web3.

Tuy nhiên, chúng ta dường như không thể nghĩ ra nhiều giải pháp có thể hoàn chỉnh như vậy, bởi vì thực sự có quá ít thảo luận và thực hành chính thống.

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

SCP các thành phần cơ bản và cách chúng hoạt động

Nói chung, SCP cũng giống như những gì cộng đồng Ethereum và Celestia gọi là “Blockchain mô-đun”, với lớp sẵn sàng dữ liệu, lớp thực thi, lớp đồng thuận, lớp Thanh toán và các mô-đun khác.

Lớp tính khả dụng của dữ liệu: Được thực hiện bởi một chuỗi công khai được công nhận và chứng minh rộng rãi hoặc các cơ sở lưu trữ dưới dạng lớp khả dụng dữ liệu, chẳng hạn như Ethereum, Arweave, Celestia, v.v. Lớp thực thi: Một máy chủ nhận và thực hiện các giao dịch của người dùng và gửi dữ liệu giao dịch được người dùng ký vào lớp DA theo lô, tương tự như trình sắp xếp của Rollup. Tuy nhiên, lớp thực thi không nhất thiết phải có cấu trúc danh sách liên kết kiểu Blockchain, nó hoàn toàn có thể là cơ sở dữ liệu Web2 + hệ thống máy tính, mà toàn bộ hệ thống máy tính phải là mã nguồn mở và minh bạch. Lớp đồng thuận: 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 thuật toán tương tự như lớp thực thi để tính toán dữ liệu để xác nhận xem đầu ra kết quả của lớp thực thi có chính xác hay không và có thể được sử dụng làm dự phòng phòng ngừa thảm họa của lớp thực thi. Người dùng cũng có thể đọc dữ liệu được trả về bởi mỗi Node trong lớp Consensus để đảm bảo rằng không có gian lận trong lớp thực thi. Lớp thanh toán: bao gồm một nhóm các nút và các hợp đồng hoặc địa chỉ khác trên chuỗi, được sử dụng để xử lý hành vi của người dùng gửi vào SCP hoặc rút khỏi SCP, hơi giống với chế độ hoạt động của các cầu nối tương tác chuỗi chéo. Lớp thanh toán Node 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 đa chữ ký hoặc Địa chỉ dựa trên TSS. Khi gửi tiền, người dùng gửi tài sản vào Địa chỉ được chỉ định của chuỗi, gửi yêu cầu khi rút tiền và Nút lớp thanh toán đọc dữ liệu và giải phóng tài sản thông qua đa chữ ký hoặc TSS. Mức độ bảo mật của lớp lắng phụ thuộc vào cơ chế tương tác chuỗi chéo được thông qua.

Khung thực hành của SCP

Mô hình SCP có thể được hiểu thông qua khuôn khổ sau đây. Một sản phẩm đáp ứng khung SCP có thể có các chức năng chính như nạp tiền, chuyển khoản, rút tiền, hoán đổi, v.v. và có thể được mở rộng hơn nữa trên cơ sở này. Sơ đồ sau đây là sơ đồ của một sản phẩm như vậy:

• Lớp DA của dự án sử dụng cơ sở lưu trữ cố định Arweave, là vòng tròn lớn trong sơ đồ. Điều phối viên, tức là lớp thực thi. **Người dùng gửi giao dịch cho điều phối viên, người thực hiện tính toán và trình bày kết quả, sau đó gửi dữ liệu đầu vào ban đầu của người dùng vào lớp DA theo lô. Máy dò, lấy dữ liệu giao dịch thô do điều phối viên gửi từ Arweave và xác thực dữ liệu và kết quả bằng Thuật toán phù hợp với điều phối viên. Máy khách dò cũng là mã nguồn mở và có thể được điều hành bởi bất kỳ ai.
• ** Watchmen, một nhóm các máy dò phụ trách đa chữ ký của hệ thống rút tiền. **Yêu cầu rút tiền được xác thực và giải ngân dựa trên dữ liệu giao dịch. Ngoài ra, người canh gác cũng chịu trách nhiệm ký đề xuất.

Chúng ta có thể thấy toàn bộ hệ thống và Sự đồng thuận mà họ đạt được đều là 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 NodeConsensus kiểu Blockchain và cho phép lớp thực thi thoát khỏi quá trình xác nhận và giao tiếp Đồng thuận nặng nề và chỉ cần thực hiện công việc của một máy chủ, để đạt được TPS và nền kinh tế gần như không giới hạn. Điều này rất giống với Rollup, nhưng SCP đã đi một con đường khác với Rollup, cố gắng chuyển từ trường hợp sử dụng quy mô cụ thể sang mô hình chuyển đổi mới từ Web2 sang Web3. **

Điều phối viên được đề cập ở 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ể làm bất cứ điều gì anh ta muốn. Tương tự như trình sắp xếp chuỗi của Rollup, sau khi gửi dữ liệu thô do người dùng gửi đến Arweave theo lô, bất kỳ ai cũng có thể chạy chương trình thử nghiệm để xác minh và so sánh nó với trạng thái do điều phối viên trả về. Ở một mức độ nào đó, đây là ý tưởng tương tự như việc áp dụng 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, ràng buộc và tách rời hai 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, nhưng điều này không ảnh hưởng đến sự tin cậy tổng thể.

Chúng ta có thể hét lên một khẩu hiệu như vậy - “** Thế hệ tiếp theo của cơ sở hạ tầng không tin cậy không phải dựa vào các giao thức đồng thuận, mà phải là các hệ thống nguồn mở và mạng nút P2P **”.

Mục đích ban đầu của mọi người để phát minh và sử dụng Blockchain là Trustless, sổ cái là nhất quán, không thể giả mạo, có thể theo dõi và các nguyên tắc cơ bản sáo rỗng khác, được nêu rõ trong Sách trắng Bitcoin. Nhưng sau Ethereum, cho dù đó là sơ đồ mở rộng quy mô của chuỗi công khai cũ, hay Rollup hay Blockchain mô-đun, mọi người đều đã hình thành một tư duy: những gì chúng ta làm phải là một Blockchain (bao gồm Giao thức đồng thuận của Node), hoặc Rollup, dường như là một giải pháp chuỗi (chỉ có cấu trúc dữ liệu Blockchain, nhưng Node không có trao đổi thông điệp đồng thuận trực tiếp).

Nhưng bây giờ, dựa trên khuôn khổ của SCP, ngay cả khi nó không phải là Blockchain, một loạt các yêu cầu như sổ cái không tin cậy, nhất quán, không giả mạo, truy xuất nguồn gốc, v.v. có thể được thực hiện, tất nhiên, tiề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, nó đảm nhận quá trình tính toán của toàn bộ hệ thống và cũng xác định loại ứng dụng nào có thể chạy trên hệ thống.

Môi trường thực thi vô hạn có thể

Về mặt lý thuyết, môi trường thực thi trong lớp thực thi có thể được thực hiện dưới mọi hình thức và khả năng là vô tận, tùy thuộc vào cách nhóm dự án định vị dự án của mình:

*Exchange. Dựa trên SCP, một sàn giao dịch mở, minh bạch và TPS cao có thể được xây dựng, có thể có các đặc điểm về tốc độ CEX và chi phí bằng không, trong khi vẫn duy trì sự phân cấp của DEX. Sự khác biệt giữa CEX và DEX trở nên mờ nhạt ở đây.

• Mạng lưới thanh toán. Tương tự như Alipay, PayPal, v.v.
• Hỗ trợ cho máy ảo / trình tải / hợp đồng Blockchain. 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.

SCP, một mô hình thiết kế hỗ trợ môi trường thực thi tùy ý, có những lợi ích độc đáo riêng: nó không còn phải dựa vào một số thành phần nhất định với hành lý lịch sử, đặc biệt là khái niệm “trừu tượng hóa tài khoản” được tạo ra bởi cộng đồng Ethereum, điều vốn không mong muốn đối với SCP.

Theo kiến trúc SCP, không có khái niệm trừu tượng hóa 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. Từ quan điểm này, nhiều trường hợp sử dụng Web2 trưởng thành không cần phải suy nghĩ lại và xây dựng để hoạt động trực tiếp trên SCP. Đây có thể là lợi ích của SCP so với Rollups. **

Minh bạch &; Bất đối xứng

Hệ thống tài khoản được đề cập ở trên và những độc giả nhạy cảm nên nhận thấy rằng mặc dù SCP có thể tận dụng hệ thống tài khoản của Web2, nhưng có vẻ như việc sử dụng nó như hiện tại có vấn đề.

Bởi vì toàn bộ hệ thống hoàn toàn minh bạch, sử dụng mô hình tương tác giữa người dùng với máy chủ trực tiếp sẽ gây ra các vấn đề nghiêm trọng, dẫn đến không có bảo mật nào cả. Hãy xem lại cách hoạt động của mô hình người dùng máy chủ truyền thống:**

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

2. Đăng nhập người dùng: Người dùng nhập tên người dùng và mật khẩu của họ vào biểu mẫu đăng nhập. Hệ thống so sánh hàm băm mật khẩu đã xử lý với giá trị băm được lưu trữ trong cơ sở dữ liệu. Nếu hai hàm băm khớp nhau, cho biết rằng người dùng đã cung cấp mật khẩu chính xác, quá trình đăng nhập sẽ tiếp tục.

3. Xác thực hoạt động: Sau khi xác minh đăng nhập được thông qua, hệ thống sẽ tạo một phiên cho người dùng. Thông thường, thông tin phiên được lưu trữ trên máy chủ và máy chủ sẽ gửi mã định danh (ví dụ: hoặc mã thông báo) đến trình duyệt hoặc ứng dụng của người dùng. Người dùng không còn cần nhập lại tên người dùng và mật khẩu cho bước tiếp theo: trình duyệt hoặc ứng dụng lưu số nhận dạng và đính kèm số nhận dạng cho mỗi yêu cầu, cho biết rằng họ có quyền từ máy chủ được liên kết.

Hãy xem lại hệ thống tương tác người dùng Web3 Blockchain-người dùng điển hình:

1. Đăng ký tài khoản: Hầu như không có quy trình đăng ký tài khoản và không có hệ thống tên người dùng-mật khẩu. Tài khoản (địa chỉ) không yêu cầu đăng ký, nó tồn tại một cách tự nhiên và bất kỳ ai nắm giữ khóa riêng của nó đều kiểm soát tài khoản. Khóa riêng được tạo ngẫu nhiên cục bộ bởi Ví và không liên quan đến quá trình mạng.

2. Đăng nhập của người dùng: Việc sử dụng Blockchain không yêu cầu đăng nhập và hầu hết các dApp không có quy trình đăng nhập, nhưng kết nối với Ví. Một số dApp sẽ yêu cầu người dùng ký và xác minh sau khi kết nối với Ví để đảm bảo rằng người dùng thực sự giữ Khóa riêng, thay vì chỉ chuyển WalletAddress đến giao diện người dùng.

3. Xác thực hoạt động: Người dùng trực tiếp gửi dữ liệu đã ký lên Node, và Node sẽ phát giao dịch đến toàn bộ mạng Blockchain sau khi xác minh, và hoạt động của người dùng sẽ được xác nhận sau khi đáp ứng được sự đồng thuận của mạng Blockchain.

Sự khác biệt giữa hai chế độ là do tính đối xứng và bất đối xứng. Trong kiến trúc người dùng máy chủ, cả hai bên đều nắm giữ cùng một bí mật. Trong kiến trúc Blockchain-User, chỉ có người dùng nắm giữ bí mật.

Mặc dù lớp thực thi của SCP không thể là một Blockchain, tất cả dữ liệu cần được đồng bộ hóa với lớp DA hiển thị công khai, vì vậy phương thức xác thực đăng nhập và hoạt động được SCP sử dụng phải không đối xứng. Tuy nhiên, vì chúng tôi không muốn có những hành động rườm rà và trải nghiệm kém ảnh hưởng đến việc áp dụng hàng loạt, chẳng hạn như cho phép người dùng giữ khóa riêng tư và sử dụng ví, các ứng dụng được xây dựng trên SCP cũng có nhu cầu sử dụng mật khẩu ID truyền thống hoặc thông tin đăng nhập xác thực ba bên OAuth, vậy làm thế nào để kết hợp cả hai?

Do tính chất bất đối xứng của mật mã bất đối xứng và các cặp bằng chứng không có kiến thức, tôi hình dung hai kịch bản có thể xảy ra:

• Nếu bạn muốn sử dụng hệ thống mật khẩu ID, bạn có thể để mô-đun lưu trữ mật khẩu này ra khỏi SCP, để không ai khác có thể nhìn thấy nó. Lớp thực thi SCP vẫn sử dụng các tài khoản khóa công khai và riêng tư của Blockchain và logic hoạt động, không cần đăng ký, đăng nhập, v.v. ID của người dùng thực sự tương ứng với khóa riêng. **Tất nhiên, khóa riêng này không thể được giữ ở phía dự án và giải pháp khả thi hơn là sử dụng 2-3 MPC để giải quyết vấn đề lưu trữ tập trung, trong khi không cho phép người dùng sử dụng khóa riêng. Khi dựa vào đăng nhập OAuth, JWT (Json Web Token) có thể được sử dụng làm phương tiện xác thực. **Phương pháp này sẽ tập trung hơn một chút so với phương pháp trên, vì về cơ bản nó cần dựa vào dịch vụ đăng nhập của bên thứ ba do nhà sản xuất Web2 cung cấp làm xác thực danh tính.

• Khi bạn đăng nhập với bên thứ ba lần đầu tiên, hãy đăng ký các trường trong JWT đại diện cho danh tính của người dùng và danh tính của nhà cung cấp dịch vụ trong hệ thống. Trong các hoạt động tiếp theo của người dùng, hướng dẫn vận hành được sử dụng làm đầu vào công khai và toàn bộ JWT được sử dụng làm nhân chứng bí mật để xác minh giao dịch của mỗi người dùng với ZKP.

Mỗi JWT có ngày hết hạn và người dùng sẽ đăng ký JWT mới vào lần đăng nhập tiếp theo, vì vậy không cần phải giữ nó mãi mãi. Ngoài ra, hệ thống này cũng cần dựa vào JWK, có thể hiểu là khóa công khai do nhà máy lớn cung cấp để xác minh JWK. Vì vậy, làm thế nào để nhập JWK Decentralization vào hệ thống, và làm thế nào để đối phó với việc luân chuyển khóa riêng trong tương lai, cũng rất đáng để khám phá.

Dù bằng cách nào, nó đắt hơn để phát triển và tính toán so với các phương pháp truyền thống, nhưng nó cũng là một cái giá cần thiết để trả cho việc phân cấp. ** Tất nhiên, nếu nhóm dự án không tin rằng Phân cấp cuối cùng 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, bạn có thể có những thiết kế này, bởi vì Phân cấp không phải là đen trắng, nhưng có một vùng màu xám ở giữa.

Quyền riêng tư

Các vấn đề minh bạch được đề cập ở trên có tác động không chỉ đến mô hình tương tác của người dùng mà còn đối với dữ liệu của người dùng. Dữ liệu của người dùng được tiếp xúc trực tiếp. Mặc dù đây không phải là vấn đề trong Blockchain, nhưng nó không được chấp nhận trong một số ứng dụng, vì vậy 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ư.

Sạc

Làm thế nào lớp thực hiện tính phí là một điểm quan tâm khác. Điều này là do cũng có chi phí liên quan đến việc gửi dữ liệu đến lớp DA, bao gồm cả hoạt động của các máy chủ của chính nó. Mục đích cốt lõi đầu tiên của Blockchain truyền thống để tính phí gas của người dùng là tránh người dùng vuốt một số lượng lớn các giao dịch lặp đi lặp lại để phá vỡ mạng lưới giao dịch và thứ hai là sắp xếp các giao dịch theo gas. Web2 không có mối quan tâm tương tự, vì vậy chỉ có các khái niệm cơ bản như lũ lụt và DDoS.

Lớp thực thi có thể tùy chỉnh các chiến lược sạc khác nhau, chẳng hạn như sạc hoàn toàn miễn phí hoặc một phần và cũng có thể kiếm tiền từ các hành vi khác như MEV (rất trưởng thành trong trình sắp xếp), hoạt động tiếp thị, v.v.

Chống kiểm duyệt

Lớp thực thi không có khả năng chống kiểm duyệt và về mặt lý thuyết có thể từ chối các giao dịch của người dùng vô thời hạn. Trong Rollup, khả năng chống kiểm duyệt có thể được đảm bảo bởi chức năng tổng hợp bắt buộc của hợp đồng L1, trong khi Sidechain hoặc chuỗi công khai là một mạng Blockchain phân tán hoàn chỉnh, cũng khó xem xét.

**Hiện tại không có giải pháp rõ ràng cho vấn đề chống kiểm duyệt, đó là một vấn đề với mô hình SCP. **

Lớp đồng thuận

Lớp này được tạo thành từ các Node lỏng lẻo và các Node này 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ỉ được sử dụng để 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ờ về tình trạng sức khỏe 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, điều này tương tự như Rollup, vì dữ liệu được gửi theo lô nên lớp thực thi luôn trả về trạng thái mới hơn cho người dùng so với 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 kết quả xác nhận trước và tính cuối cùng mềm, vì nó chưa được gửi đến lớp DA;

** Lớp đồng thuận cung cấp cho người dùng tính cuối cùng cứng. 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 tương tác chuỗi chéo, phải tuân theo tính cuối cùng cứng. Ví dụ: hệ thống gửi và rút tiền của sàn giao dịch sẽ không tin tưởng vào dữ liệu được phát bởi bộ nối tiếp Rollup ngoài chuỗi và phải đợi dữ liệu này được tải lên Ethereum trước khi nó được công nhận.

Ngoài việc được sử dụng để xác nhận kết quả, lớp Đồng thuận còn đóng một vai trò quan trọng, đó là dự phòng thảm họa như một lớp thực thi. **Nếu lớp thực thi tấn công vĩnh viễn và làm điều ác nghiêm trọng, tại thời điểm này, 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à nhận 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 một Node ổn định và đáng tin cậy làm máy chủ cho lớp thực thi.

Lớp giải quyết

Vì SCP không phải là Rollup, nó không thể đạt được rút tiền Trustless hoàn toàn dựa trên mật mã và mã Hợp đồng thông minh mà không có sự can thiệp của con người như lớp thanh toán rút tiền của Rollup. Cầu nối tương tác chuỗi chéo SCP giống như Cầu nối tương tác chuỗi chéo của nhân chứng bên thứ ba hoặc bên thứ ba và cần dựa vào các nhà quản lý đa chữ ký được ủy quyền để giải phóng tài sản, mà chúng tôi gọi là mô hình nhân chứng.

Phân cấp cầu nhân chứng càng nhiều càng tốt là chủ đề của nhiều nghiên cứu tương tác chuỗi chéo. Do hạn chế về không gian, tôi sẽ không mở rộng nó ở đây. Một nền tảng SCP được thiết kế tốt cũng phải có các đối tác đa chữ ký Decentralization Bridge có uy tín trong thực tế.

** Người ta có thể hỏi tại sao SCP không sử dụng các chuỗi có hợp đồng thông minh làm lớp DA?** Điều này có thể tạo ra một lớp thanh toán cung cấp hợp đồng và hoàn toàn không đáng tin cậy.

Về lâu dài, miễn là khắc phục được một số khó khăn kỹ thuật, nếu lớp DA được đặt trên lớp DA với các hợp đồng như Ethereum và hợp đồng xác minh tương ứng có thể được xây dựng, SCP cũng có thể có được bảo mật thanh toán tương tự như Rollup, mà không cần sử dụng đa chữ ký.

Nhưng trong thực tế, điều này không nhất thiết là tối ưu:**

1. Ethereum không được sử dụng đặc biệt để bảo quản dữ liệu và giá quá cao so với chuỗi công khai lưu trữ dữ liệu thuần túy. Đố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ỉ bằng cách này, thông lượng cấp Web2 mới có thể được hỗ trợ.

2. Chứng minh rằng hệ thống rất khó phát triển, bởi vì SCP không chỉ có thể mô phỏng EVM mà còn thực hiện bất kỳ logic nào. ** Nhìn vào thực tế là các nhóm như Optimism vẫn chưa trực tuyến để chống gian lận và khó khăn trong việc phát triển zkEVM, chúng ta có thể tưởng tượng rằng việc triển khai bằng chứng của các hệ thống khác nhau trên Ethereum là vô cùng khó khăn.

Do đó, giải pháp Rollup chỉ thực tế tốt hơn trong các tình huống cụ thể và nếu bạn có kế hoạch thực hiện một cách tiếp cận rộng hơn và cởi mở hơn, tránh xa hệ thống EVM và chuyển sang nhiều tính năng Web2 hơn, ý tưởng về Ethereum Rollup là không phù hợp.

**SCP không phải là một sơ đồ mở rộng quy mô chuỗi công khai, mà là một kiến trúc nền tảng điện toán Web3 lớn hơn, vì vậy rõ ràng không cần phải tuân theo ý tưởng về Ethereum Lớp 2. **

** Sơ đồ so sánh SCP với các mô hình khác**