Nguồn ban đầu: joncharbonneau.substack.com
Tác giả: Jon Charbonneau
tiêu đề cấp đầu tiên
giới thiệu
Kelvin nghĩ ZK-rollup là không có thật, nhưng tôi nghĩ bất kỳ"rollup"Không phải là sự thật, ít nhất là chưa. Vì vậy, làm cách nào để chúng tôi biến chúng thành danh sách thực sự?
Mô tả hình ảnh
Nguồn: L2 Beat
Trong bài viết này, tôi sẽ phác thảo các khía cạnh sau:
Cơ chế đóng gói giao dịch bắt buộc— Ngay cả trong trường hợp các nhà khai thác tổng số kiểm duyệt người dùng, người dùng vẫn có thể buộc các giao dịch của họ phải chống lại sự kiểm duyệt.
Phân cấp trình tự L2 và (tùy chọn) sự đồng thuận cục bộ— Trình tự sắp xếp loại đơn, PoA, bầu chọn người lãnh đạo PoS, đồng thuận PoS, đấu giá MEV, tổng hợp dựa trên lớp cơ sở, PoE, v.v.
Trình tự chia sẻ và nguyên tử chuỗi chéo- Đây là một cái gì đó thực sự thú vị và hoàn toàn mới.
Thiết kế có thể chụp MEV- Tôi sẽ giới thiệu sơ lược về một số thay đổi trong FCFS (First Come First Served). Đối với nhóm giao dịch được mã hóa, bạn có thể tham khảo bài đăng gần đây của tôi.
tiêu đề cấp đầu tiên
tiêu đề phụ
Tổng hợp hợp đồng thông minh (SCR)
Đầu tiên, hãy xem xét ngắn gọn nguyên tắc hoạt động của SCR, đây là một bản tổng hợp phổ biến trên Ethereum. Ở cấp độ cao, một SCR về cơ bản bao gồm:
1. Một loạt các mảng đầu vào được sắp xếp (trên L1, vì vậy dữ liệu giao dịch phải được xuất bản trên lớp DA).
2. (phần mềm nút cuộn) mã chạy trên chúng.
Mô tả hình ảnh
cr: How Rollups *actually* work - Kelvin Fichter
Cụ thể hơn, trình sắp xếp thứ tự truyền thống tạo ra cam kết đối với khối tổng số bằng cách xuất bản gốc trạng thái của khối tổng số và dữ liệu gọi (cuối cùng ở dạng đốm dữ liệu) vào hợp đồng thông minh của nó tại L1. Các khối mới liên tục mở rộng tiêu đề khối cặp tổng số. Hợp đồng trên chuỗi chạy một ứng dụng khách ánh sáng cuộn lên để lưu hàm băm của tiêu đề khối của nó. Khi nhận được bằng chứng hợp lệ hoặc sau khi cửa sổ chống gian lận hết hạn, hợp đồng thông minh sẽ hoàn tất việc thanh toán. Nếu một khối ORU chưa hoàn thiện không hợp lệ, thì khối đó (và tất cả các khối tiếp theo) sẽ bị hủy bỏ do các cam kết cặp bằng chứng gian lận và cuối cùng trở thành mồ côi. Bằng chứng giúp bắc cầu an toàn:
Việc gửi các lô giao dịch cần phải áp dụng một số loại quy tắc ký quỹ/ký quỹ để ngăn chặn hành vi nguy hiểm xảy ra. Ví dụ: khi một lô gian lận được gửi (tức là trạng thái gốc không hợp lệ), khoản tiền gửi sẽ bị hủy và phân phối cho người thách thức gian lận theo một tỷ lệ nào đó.
SCR có "sự đồng thuận hợp nhất" - một giao thức đồng thuận có thể kiểm chứng trên chuỗi. Giao thức Rollup có thể chạy hoàn toàn trong các hợp đồng thông minh L1. Nó không ảnh hưởng đến các quy tắc đồng thuận tùy ý của chuỗi chính và cũng không yêu cầu sự hỗ trợ của các quy tắc đó.
Các giao thức đồng thuận phi tập trung thường bao gồm bốn đặc điểm chính (lưu ý rằng sau đây là phiên bản rất đơn giản và không liệt kê đầy đủ các loại giao thức đồng thuận khác nhau. Chẳng hạn như các giao thức không có người lãnh đạo):
1. Chức năng hợp lệ khối- Các hàm chuyển trạng thái. Tính hợp lệ của khối được thực thi ngoài chuỗi và sau đó tính hợp lệ của nó được chứng minh bằng cơ chế chứng minh tính hợp lệ hoặc bằng chứng gian lận.
2. Quy tắc lựa chọn fork- Cách chọn giữa hai chuỗi hợp lệ khác. Rollup được thiết kế để không có fork khi xây dựng, do đó không bắt buộc phải có quy tắc lựa chọn fork phức tạp.
3. Thuật toán bầu chọn thủ lĩnh- Bầu chọn một nhà lãnh đạo có thể mở rộng chuỗi khối bằng cách thêm các khối mới để mở rộng đầu chuỗi.
4. Cơ chế chống Sybil- PoW, PoS, v.v.
Có thể coi như đã đạt được 1 và 2, thì yêu cầu tối thiểu để phân cấp trình tự là một số hình thức tấn công Sybil + bầu chọn thủ lĩnh. Fuel Labs từ lâu đã ủng hộ trại này, lập luận rằng PoS:
Không nên được sử dụng cho một giao thức đồng thuận đầy đủ trong tổng số (tức là người xác thực/người đặt hàng tổng số sẽ bỏ phiếu cho các khối)
Chỉ nên được sử dụng để bầu chọn người lãnh đạo trong tổng số
tiêu đề phụ
Rollup có chủ quyền (SR)
SR vẫn xuất bản dữ liệu giao dịch lên L1 cho DA và sự đồng thuận, nhưng SR xử lý ứng dụng khách "thanh toán" trong bản tổng hợp (James Prestwich nói "lớp thanh toán" là ngu ngốc, tôi đã ngu ngốc rồi nên không thành vấn đề ). Lớp DA cho bạn biết rằng dữ liệu tồn tại, nhưng nó không xác định chuỗi chính tắc mà tổng số là:
SCR - chuỗi chuẩn rollup được xác định bởi hợp đồng thông minh L1
Mô tả hình ảnh
Nguồn: Celestia
Về một lưu ý liên quan: Một điểm thú vị đã được đưa ra là không có chuỗi chính tắc toàn cầu (chỉ có cây cầu quyết định chuỗi nào là chuỗi chính tắc) và một lập luận phản bác mạnh mẽ đã được đưa ra về vấn đề này. và các tweet dài có liên quan khác minh họa sự đánh đổi giữa chủ quyền và khả năng kết hợp (tự động). Tôi khuyến khích bạn xem qua các quan điểm này, cũng như dòng tweet dài gần đây này về đợt tổng hợp chủ quyền Bitcoin.
tiêu đề cấp đầu tiên
tiêu đề phụ
Gói giao dịch bắt buộc do người dùng thực hiện
Tổng hợp hợp đồng thông minh
Như đã đề cập ở trên, trình sắp xếp thứ tự thường chịu trách nhiệm xử lý các giao dịch theo đợt và xuất bản chúng lên hợp đồng thông minh L1. Tuy nhiên, người dùng cũng có thể trực tiếp chèn một số giao dịch vào hợp đồng:
Tất nhiên, điều này không hiệu quả và tốn kém, vì vậy trình sắp xếp thứ tự sẽ xử lý các giao dịch theo đợt và gửi các đợt này cùng nhau trong quy trình thông thường. Điều này khấu hao chi phí cố định trên nhiều giao dịch, cho phép nén tốt hơn:
Trình sắp xếp thứ tự cam kết cuối cùng sẽ xuất bản các giao dịch này trên L1, trong khi chúng tôi có thể tính toán đầu ra để xác nhận trước nhẹ nhàng hơn:
Đầu ra được hoàn thành khi trình sắp xếp thứ tự xuất bản các giao dịch này lên L1:
Thông thường, người dùng chỉ cần tự gửi giao dịch khi bắc cầu tài sản từ L1 sang L2. Điều này được thêm vào dưới dạng đầu vào cho hợp đồng L1, cho L2 biết rằng đã đến lúc đúc tiền được hỗ trợ bởi tài sản bị khóa L1 tương ứng.
Nếu tôi muốn rút tiền của mình về L1, tôi có thể hủy nó trên L2 và yêu cầu L1 trả lại tiền cho tôi. L1 không biết chuyện gì đã xảy ra với L2 (L1 không thực hiện các giao dịch), do đó cần gửi bằng chứng cùng với yêu cầu mở khóa tiền của tôi trên L1.
Vì tôi đến từ L2, trình sắp xếp thứ tự có thể bắt đầu yêu cầu rút tiền này và cam kết với L1. Tuy nhiên, làm như vậy có nghĩa là bạn cần tin tưởng vào khả năng chống kiểm duyệt (CR, censorship resistance) của trình sắp xếp thứ tự L2, điều đó có nghĩa là bạn sẽ không còn nhận được sự đảm bảo an ninh như L1 nữa. Có thể trình sắp xếp thứ tự không thích bạn hoặc trình tự sắp xếp bị lỗi, vì vậy bạn bị mắc kẹt trên L2 mãi mãi.
Rollup có thể cải thiện CR cục bộ thông qua các biện pháp khác nhau. Điều này có thể bao gồm các bộ đồng thuận L2 với cổ phần có giá trị cao, các biến thể khác nhau của một số danh sách gói giao dịch, thêm mã hóa ngưỡng, v.v. để giảm thiểu khả năng kiểm duyệt người dùng L2. Điều đó thật tuyệt, nhưng lý tưởng nhất là chúng tôi muốn người dùng L2 có được các đảm bảo chống kiểm duyệt giống như L1.
Mô tả hình ảnh
Nguồn: Nghiên cứu về Starknet Escape Hatch
Tuy nhiên, điều này không lý tưởng nếu tùy chọn duy nhất cho người dùng L2 là buộc giao dịch trực tiếp vào L1. Điều này có thể không khả thi đối với nhiều người dùng có giá trị thấp, đặc biệt khi các tương tác L1 ngày càng trở nên tốn kém. Các thiết kế nâng cao hơn có thể khắc phục hạn chế này bằng cách buộc các giao dịch nguyên tử giữa các lần tổng hợp. Kalman Lajkó đang làm việc trên một thiết kế hấp dẫn mà tôi khuyên bạn nên đọc. Nó hy vọng sẽ cho phép đóng gói giao dịch bắt buộc cuộn chéo trong các hệ thống có bằng chứng được chia sẻ và các lớp DA được chia sẻ.
Rollup có chủ quyền
Đóng gói cưỡng bức hoạt động khác trong SR bởi vì, như đã đề cập trước đó, chúng thực thi các quy tắc lựa chọn ngã ba khác với SCR (Sovereign Labs đã viết một bài đăng về điều này).
Trong SCR, hợp đồng thông minh L1 thực hiện các quy tắc lựa chọn fork của rollup. Ngoài việc xác thực bằng chứng ZK, nó cũng kiểm tra xem bằng chứng có được xây dựng dựa trên các bằng chứng trước đó (chứ không phải các nhánh bằng chứng khác) và rằng nó đã xử lý tất cả các giao dịch đưa vào bắt buộc có liên quan được gửi trên L1.
SR có thể xuất bản bằng chứng ZK của mình lên lớp L1 DA, cung cấp chúng cho mọi người ở dạng calldata/blobs (ngay cả khi L1 không xác minh chúng). Sau đó, chỉ cần thêm quy tắc rằng bằng chứng mới chỉ hợp lệ nếu nó được xây dựng dựa trên bằng chứng hợp lệ trước đó. Quy tắc này có thể được thực thi phía máy khách, nhưng sau đó nó yêu cầu người dùng quét lịch sử của chuỗi cho đến khối genesis hoặc một số điểm kiểm tra.
Ngoài ra, calldata có thể được liên kết với tiêu đề khối L1 và có thể thêm một câu lệnh "Tôi đã quét bằng chứng của lớp DA (bắt đầu từ khối X và kết thúc bằng khối Y) và bằng chứng này dựa trên hiệu quả mới nhất xây dựng bằng chứng". Điều này trực tiếp chứng minh quy tắc lựa chọn ngã ba trong bằng chứng mà không thực thi nó ở phía khách hàng.
tiêu đề phụ
Hệ thống phân cấp hoàn tất giao dịch & ZK để hoàn tất nhanh
Việc xác minh bằng chứng trên chuỗi trên Ethereum thường rất tốn kém, vì vậy các ZKR hiện tại (như StarkEx) có xu hướng chỉ phát hành STARK cho Ethereum cứ sau vài giờ. Liên quan đến số lượng giao dịch, sự tăng trưởng của bằng chứng thường rất chậm, vì vậy việc tạo các đợt giao dịch theo cách này có thể tiết kiệm chi phí một cách hiệu quả. Tuy nhiên, thời gian quyết toán dài như vậy không phải là lý tưởng.
Nếu một bản tổng hợp chỉ xuất bản sự khác biệt về trạng thái trên chuỗi (chứ không phải dữ liệu giao dịch đầy đủ), thì ngay cả các nút đầy đủ cũng không thể đảm bảo tính cuối cùng này nếu không có bằng chứng. Nếu dữ liệu giao dịch hoàn chỉnh của cuộn tổng số được xuất bản lên chuỗi, thì ít nhất bất kỳ nút đầy đủ nào cũng có thể hoàn tất giao dịch với L1.
Thông thường, các nút nhẹ chỉ dựa vào trình sắp xếp tập trung để xác nhận mềm. Tuy nhiên, ZKR có thể nhanh chóng tạo và phân phối các bằng chứng ZK ở lớp p2p để tất cả các ứng dụng khách nhẹ có thể xem trong thời gian thực và cung cấp cho họ tính hữu hạn ở tốc độ L1. Sau đó, những bằng chứng này có thể được đệ quy theo đợt và xuất bản lên L1.
Đây là những gì Sovereign Labs dự định thực hiện và có các kế hoạch tương tự khác như Scroll, kế hoạch xuất bản các bằng chứng ZK trung gian trên chuỗi (nhưng không xác minh chúng), vì vậy các máy khách nhẹ có thể đồng bộ hóa khá nhanh. Sử dụng hai cấu trúc này, quá trình tổng số có thể bắt đầu hoàn thiện các khối ở tốc độ L1, thay vì chờ gửi lô đến chuỗi để tiết kiệm chi phí. Tuy nhiên, lưu ý rằng trong cả hai trường hợp, "thời gian loại trực tiếp khó" chỉ được giảm xuống mức tối thiểu tuyệt đối (tốc độ L1).
Các thiết kế trình tự sắp xếp khác nhau sẽ không bao giờ được hoàn thiện nhanh hơn thời gian khối L1. Điều tốt nhất mà các thiết kế trình tự sắp xếp khác nhau có thể làm là cung cấp xác nhận trước nhanh hơn so với thời gian khối L1, với các mức độ chắc chắn khác nhau được cung cấp bởi các thiết kế khác nhau (ví dụ: bạn có thể tin tưởng vào xác nhận trước L2 phi tập trung của bộ đồng thuận, thay vì xác nhận trước của một trình tự sắp xếp đáng tin cậy một loại).
Patrick McCorry gần đây cũng đã đưa ra một cái nhìn tổng quan về các lớp cuối cùng cho các giao dịch tổng số. Đến đây chắc bạn đã hiểu những khái niệm cơ bản:
"Tính cuối cùng" của giao dịch có các cấp độ khác nhau tùy thuộc vào người cung cấp cam kết (và cấu trúc tổng số như thế nào)
tiêu đề phụ
trình tự loại đơn
Hiện tại, hầu hết các bản tổng hợp đều có trình sắp xếp thứ tự được phép gửi các lô giao dịch. Điều này rất hiệu quả, nhưng ít khả thi hơn và ít bị kiểm duyệt hơn. Điều này có thể được chấp nhận đối với nhiều trường hợp sử dụng, với các biện pháp bảo vệ thích hợp:
CR — Các cơ chế bao gồm các giao dịch do người dùng bắt buộc, như được mô tả ở trên.
tích cực— Một số tùy chọn sao lưu nóng nếu một số trình sắp xếp thứ tự chính bị hỏng (chẳng hạn như bản sao lưu bằng chứng gian lận ZKR và ORU không được phép). Nếu trình sắp xếp dự phòng cũng bị hỏng, bất kỳ ai cũng có thể tiếp quản.
Ví dụ: một trình sắp xếp dự phòng có thể được bầu bởi quản trị của tổng số. Với thiết lập này, người dùng có được tính bảo mật, khả năng chống kiểm duyệt và sự sống động. Ngay cả trong thời gian dài, một trình sắp xếp chuỗi hoạt động duy nhất có thể là một lựa chọn khả thi.
Cơ sở rất có thể là sự khởi đầu của một xu hướng. Các công ty hiện có thể quản lý và tối ưu hóa các dịch vụ của họ nhiều như họ đã thổi phồng về các chuỗi khối doanh nghiệp, nhưng giờ đây nó thực sự có thể là một chuỗi không được phép, an toàn và có thể tương tác.
Base dự định cuối cùng sẽ phi tập trung hóa bộ trình tự sắp xếp của họ, nhưng vấn đề là họ không "cần" phân cấp nghiêm ngặt, trong khi các kế hoạch khác thì không (hoặc chỉ cần phân quyền ở một mức độ rất hạn chế, chẳng hạn như một bộ trình tự sắp xếp nhỏ). Rõ ràng, điều này yêu cầu các bản tổng hợp triển khai các bước cần thiết để đảm bảo rằng các bản tổng hợp được bảo mật và duy trì khả năng chống kiểm duyệt (xóa các tính năng nâng cấp tức thì tùy ý, triển khai bằng chứng mạnh mẽ, thực thi đóng gói giao dịch, đấu giá MEV, v.v.). Và tổng số hiện tại không an toàn.
Đây sẽ là một cải tiến lớn so với các dịch vụ tập trung/lưu ký, chứ không thay thế các dịch vụ phi tập trung. Rollup chỉ đơn giản là mở rộng không gian thiết kế. Đây cũng chính là lý do tại sao phân cấp trình tự sắp xếp không phải là ưu tiên hàng đầu đối với hầu hết các nhóm tổng số - các mục khác quan trọng hơn nhiều để đảm bảo bảo mật người dùng, chống kiểm duyệt và giảm lòng tin vào người vận hành tổng số.
tiêu đề phụ
Bằng chứng về thẩm quyền (PoA)
Một cải tiến ngay lập tức đối với các trình sắp xếp thứ tự loại đơn là cho phép triển khai một số lượng nhỏ các trình sắp xếp thứ tự (có thể là các công ty có uy tín khác) được phân phối theo địa lý. Trình sắp xếp thứ tự có thể chỉ cần xoay đều theo kiểu vòng tròn. Yêu cầu họ đăng một trái phiếu sẽ giúp khuyến khích hành vi trung thực.
tiêu đề phụ
Đấu giá Sequencer hay còn gọi là Đấu giá MEV (MEVA)
Mô tả hình ảnh
Nguồn: Phân cấp ZK Rollups
tiêu đề phụ
PoS không cần cấp phép cho cuộc bầu cử lãnh đạo
Bất kỳ ai cũng có thể tham gia với tư cách là trình sắp xếp thứ tự mà không cần được phép, nhưng chỉ khi có cổ phần (có thể là mã thông báo gốc của L2). Cơ chế cam kết có thể được thiết lập ở lớp cơ sở thông qua hợp đồng thông minh hoặc có thể được thiết lập trực tiếp trong tổng số. Rollup có thể sử dụng PoS này + một số dạng ngẫu nhiên trên chuỗi để triển khai cơ chế lựa chọn người dẫn đầu (giống như một số L1 đã làm).
Xác suất mà bất kỳ ai cũng có quyền sắp xếp các khối = tỷ lệ số tiền cam kết của ta trên tổng số tiền cam kết. Các hình phạt có thể được áp dụng đối với trình tự sai/độc hại thông qua phần thưởng thua lỗ, hình phạt phá hoại và chém.
Lưu ý rằng điều này không yêu cầu sự đồng thuận của trình sắp xếp thứ tự vì những lý do trên. Tổng số sử dụng L1 làm sự đồng thuận, vì vậy không cần có sự đồng thuận cục bộ. Trọng số đặt cược đóng vai trò chủ đạo trong cơ chế xoay vòng, xác định trình tự sắp xếp nào có thể đề xuất các khối, nhưng họ không bắt buộc phải bỏ phiếu cho các khối do các trình sắp xếp khác đề xuất.
Điều này cấp quyền đặt hàng cho các kỷ nguyên có độ dài tùy ý. Một người tham gia có thể có quyền đặt hàng 100 khối tổng số liên tiếp hoặc 1000, v.v. Các chu kỳ dài hơn có thể hiệu quả hơn và chỉ yêu cầu một bộ giải trình tự tại một thời điểm nhất định. Tuy nhiên, trao quyền cho độc quyền mở rộng cũng có những tác động bên ngoài khác. Ngoài ra, người lãnh đạo có thể luân phiên từng khối như L1 bình thường.
Dymension
Dymension là một trong những dự án như vậy. Dymension Hub sẽ là một L1 điển hình trong Cosmos sử dụng cơ chế PoS đa số trung thực. Các L2 của nó ("RollApp") sẽ sử dụng nó để giải quyết và đồng thuận, trong khi dựa vào Celestia như một kho lưu trữ dữ liệu sẵn có (do đó, các L2 này thực sự là một "chuỗi lạc quan" chứ không phải là "tổng số").
Theo Litepaper của họ, việc phân loại RollApp phi tập trung sẽ yêu cầu đặt cược DYM (tài sản gốc của Dymension) trong Trung tâm Dymension. Cuộc bầu chọn người dẫn đầu được xác định bởi số tiền đặt cược DYM tương ứng. Những trình sắp xếp thứ tự này sẽ kiếm được doanh thu (phí và MEV khác) từ các lần tổng hợp tương ứng của chúng, sau đó thanh toán cho Dymension Hub và Celestia các chi phí cơ bản có liên quan.
Nhờ cơ chế này, hầu hết tất cả giá trị thu được trong ngăn xếp này được tích lũy trực tiếp vào mã thông báo DYM. Các bản tổng hợp sử dụng mã thông báo gốc của chúng để sắp xếp (như StarkNet dự định thực hiện với STRK, được mô tả bên dưới) sẽ tích lũy giá trị vào mã thông báo của riêng chúng. Cài đặt của Dymension Hub tương tự như cài đặt của Ethereum rollup, cài đặt này chỉ có thể sử dụng ETH để bầu chọn trình tự sắp xếp.
tiêu đề phụ
PoS không cần cấp phép cho Bầu cử lãnh đạo & Đồng thuận L2
Cam kết L2 cũng có thể được sử dụng cho các cuộc bầu chọn trình tự sắp xếp và sự đồng thuận cục bộ L2 trước khi hoàn thiện L1 nếu muốn.
PoS Sequencer bầu chọn lãnh đạo— Như đã đề cập ở trên, một số hình thức bầu chọn lãnh đạo là cần thiết.
đồng thuận PoS— Khuyến khích những người xác thực L2 đạt được sự đồng thuận L2 tạm thời trước khi giao dịch được hoàn tất bởi L1, mang lại khả năng xác nhận trước mạnh mẽ hơn. Như đã đề cập ở trên, điều này không bắt buộc, nhưng nó là một lựa chọn hấp dẫn.
Ngoài ra, STRK có thể được sử dụng dưới một số hình thức để:
Sự đồng thuận PoS của DA— Được sử dụng để khuyến khích cung cấp các chuỗi DA thay thế (alt-DA, chẳng hạn như ý chí), đòi hỏi phải có sự đồng thuận riêng.
chứng minh— Khuyến khích người chứng minh tạo ra STARK.
Quy trình giao dịch như sau:
1. Trình tự— Trình sắp xếp thứ tự giao dịch và đề xuất một khối
2. Đồng thuận L2— Giao thức đồng thuận StarkNet ký các khối được đề xuất
3. Tạo bằng chứng— Prover tạo ra một bằng chứng cho một khối đồng thuận
4. Cập nhật trạng thái L1— Gửi bằng chứng cho L1 để cập nhật trạng thái
tiêu đề phụ
Cần có sự đồng thuận L2 hay chỉ sự đồng thuận L1?
Như chúng ta đã thấy, L2 có thể hoặc không thể triển khai sự đồng thuận cục bộ của riêng mình (tức là, trình xác thực L2 ký các khối của họ trước khi gửi chúng đến L1 để có sự đồng thuận cuối cùng). Ví dụ: hợp đồng thông minh L1 có thể phản ứng khác nhau dựa trên các quy tắc riêng của chúng:
PoS sử dụng bầu chọn lãnh đạo và sự đồng thuận cục bộ— “Tôi chỉ chấp nhận các khối được ký bởi sự đồng thuận L2.”
PoS sử dụng bầu chọn lãnh đạo— "Hiện tại, chỉ những trình tự được chọn mới có thể gửi khối."
Nếu tổng số không có sự đồng thuận cục bộ, tất cả những gì cần làm là:
Làm cho quy trình đề xuất khối tổng số không được phép.
Tạo một số tiêu chí để chọn khối tốt nhất cho chiều cao khối nhất định
Có các nút hoặc hợp đồng thanh toán thực thi các quy tắc lựa chọn ngã ba
Sự đồng thuận và tính hữu hạn kế thừa từ L1
Lưu ý rằng trong cả hai trường hợp, giá trị của L2 có thể được tích lũy thành mã thông báo tổng số. Ngay cả khi mã thông báo L2 chỉ được sử dụng cho một số hình thức bầu chọn người lãnh đạo (chứ không phải bỏ phiếu đồng thuận), giá trị được tạo bởi quyền đặt hàng vẫn sẽ tích lũy vào mã thông báo L2.
Nhược điểm của sự đồng thuận L2 (chỉ bầu chọn lãnh đạo)
Bây giờ, hãy thảo luận về sự đánh đổi giữa việc có/không có sự đồng thuận cục bộ trước khi L1 được hoàn thiện.
Một lập luận do nhóm Fuel Labs đưa ra là sự đồng thuận cục bộ của L2 làm giảm khả năng chống kiểm duyệt. "Điều này cho phép phần lớn các trình xác thực kiểm duyệt các khối mới, điều đó có nghĩa là tiền của người dùng có thể bị đóng băng. Các đợt tổng hợp không cần PoS bảo vệ vì các đợt tổng hợp được bảo mật bởi Ethereum." Như đã đề cập trước đó, ngay cả khi trình sắp xếp thứ tự dường như kiểm duyệt các giao dịch, các bản tổng hợp vẫn có thể cung cấp các sơ đồ chống kiểm duyệt (ví dụ: trực tiếp buộc các giao dịch vào L1 hoặc các thiết kế phức tạp hơn như thiết kế mà Kalman Lajkó đang thực hiện).
Nói cách khác, sự đồng thuận hoàn toàn chỉ là"hiệu quả thấp". Ví dụ:
chỉ có một nhà lãnh đạo trình tự duy nhất chạy mọi thứ trong một hộp duy nhất tại một thời điểm,
Chỉ có một nhà lãnh đạo đặt hàng duy nhất chạy mọi thứ trong một hộp tại một thời điểm và sau đó tất cả các nút khác cần bỏ phiếu cho đề xuất và đạt được sự đồng thuận,
Cái trước đơn giản hơn nhiều so với cái sau.
Tất nhiên, điều này thay đổi rất nhiều với thiết kế trình tự sắp xếp cụ thể và cơ chế đồng thuận được chọn.
Ngoài ra, xin lưu ý rằng một số người đã nêu lên mối lo ngại về việc sử dụng PoS trong phân quyền theo trình tự, chẳng hạn như tại đây và tại đây. Mối quan hệ phức tạp của L1 với L2 có thể khiến việc đối phó với một số kiểu tấn công trở nên khó khăn hơn.
Đã thêm lợi ích của sự đồng thuận L2 (cộng với bầu chọn lãnh đạo)
Có lẽ mục tiêu lớn nhất của trình sắp xếp thứ tự là cung cấp cho người dùng xác nhận mềm nhanh hơn trước sự an toàn đầy đủ do L1 cung cấp. Hãy xem các yêu cầu về cơ chế của StarkNet:
"Tính hữu hạn của L2 mạnh mẽ và nhanh chóng là mục tiêu của StarkNet. Vì trạng thái của StarkNet chưa được hoàn thiện cho đến khi lô giao dịch được chứng minh bởi L1 (có thể mất vài giờ). Do đó, trước khi đợt tiếp theo được chứng minh, L2 sẽ chuyển sang các giao thức tập trung nên đưa ra các cam kết có ý nghĩa về thứ tự thực hiện các giao dịch được lên kế hoạch.”
Việc thêm một số hình thức đồng thuận (được hỗ trợ bởi bảo mật kinh tế do nhiều người đặt hàng cung cấp) có thể giúp mang lại sự đảm bảo mạnh mẽ hơn trong thời gian này (xác nhận trước các khối tổng số cũng được):
"Sự đồng thuận của Starknet phải có ý thức trách nhiệm cao rằng các hành vi vi phạm an ninh và tính sống động có thể được thực thi bằng cách cắt giảm bất kỳ bộ phận nào của người tham gia, bao gồm cả phần lớn cổ phần độc hại."
tiêu đề phụ
L1 chịu trách nhiệm sắp xếp Rollup
Tất cả các phương pháp trên đều đặc quyền cho trình sắp xếp chuỗi để tạo các khối tổng số ở một số dạng. Ví dụ: PoS không được phép tham gia, nhưng trình sắp xếp thứ tự L2 đã chọn cho một vị trí nhất định là bên duy nhất có thể cam kết một khối tại thời điểm đó. Ngoài ra, có những đề xuất liên quan để không đặc quyền cho bất kỳ trình sắp xếp thứ tự L2 nào. Những thiết kế này dựa vào chính L1 để đặt hàng giao dịch.
hoàn toàn "vô chính phủ"
Vitalik đã đưa ra ý tưởng "hoàn toàn vô chính phủ" này vào năm 2021. Bất cứ ai cũng được phép gửi các lô giao dịch bất cứ lúc nào. Giao dịch đầu tiên để gia hạn tổng số sẽ được chấp nhận. Nó đáp ứng hai yêu cầu tối thiểu đã thảo luận ở trên về cách phân cấp trình sắp xếp thứ tự:
chống phù thủy— Khả năng chống lừa đảo (tức là phí giao dịch và kích thước khối/giới hạn gas) do L1 cung cấp.
bầu cử lãnh đạo— Cuộc bầu cử lãnh đạo là ngầm định và bị trì hoãn.
Điều này là đủ vì L1 đã cung cấp bảo mật. Nếu các khối L2 đã được xuất bản lên L1, chúng sẽ chỉ trở thành mồ côi nếu chúng không hợp lệ hoặc được xây dựng trên các khối không hợp lệ (sẽ được khôi phục). Nếu chúng hợp lệ và được xuất bản lên L1, thì chúng có các đảm bảo bảo mật giống như chính L1.
Vitalik chỉ ra rằng một vấn đề lớn với giải pháp này là hiệu quả của nó sẽ rất thấp. Nhiều người tham gia có thể gửi các đợt song song và chỉ một đợt sẽ được đóng gói thành công. Điều này gây lãng phí rất nhiều năng lượng khi tạo bằng chứng hoặc rất nhiều gas không cần thiết để phát hành các lô giao dịch. Sẽ rất rườm rà và không hiệu quả để biết liệu giao dịch của bạn có sớm được đưa vào hay không.
Rollup dựa trên chuỗi cơ bản (Based Rollups)
Tuy nhiên, thiết kế vô chính phủ này hiện có thể được thực hiện thông qua PBS. Nó cho phép đặt hàng chặt chẽ hơn, với tối đa một khối tổng số trên mỗi khối L1, do đó không lãng phí khí. (Mặc dù có thể có tính toán lãng phí). Trình tạo L1 chỉ có thể bao gồm khối tổng số có giá trị cao nhất và tạo khối đó dựa trên giá thầu đầu vào của người tìm kiếm, tương tự như bất kỳ khối L1 nào. Để tránh lãng phí tính toán, theo mặc định, quy trình chứng minh ZK không được phép (với các cơ chế tương ứng cho phép khôi phục không được phép) cũng hợp lý.
Đây là ý tưởng cốt lõi của "Rollup dựa trên chuỗi cơ bản" do Justin Drake đề xuất gần đây. Anh ấy sử dụng thuật ngữ này để chỉ các bản tổng hợp trong đó L1 (lớp "cơ sở") chi phối thứ tự. Những người đề xuất L1 chỉ cần đảm bảo bao gồm các khối tổng số trong các khối L1 của riêng họ (có lẽ thông qua các trình tạo). Đây là một thiết lập đơn giản cung cấp ngay lập tức sự sống động và phân cấp của L1. Họ có thể tránh được một số vấn đề phức tạp như giải quyết các giao dịch đóng gói bắt buộc trong khi trình sắp xếp thứ tự L2 đang xem xét chúng. Ngoài ra, một số chi phí gas có thể được giảm do không cần xác minh chữ ký trình tự.
Một câu hỏi thú vị là các giao dịch L2 này được xử lý ở đâu. Các máy khách L2 cần gửi các giao dịch này đến một nơi nào đó để người tìm kiếm/người xây dựng L1 có thể nhận chúng và tạo các khối cũng như khối dữ liệu chống lại chúng. Chúng có thể được gửi đến:
Nhóm giao dịch L1— Chúng có thể được gửi đến những người tìm kiếm/nhà xây dựng "có hiểu biết" cùng với một số siêu dữ liệu đặc biệt để diễn giải chúng. Tuy nhiên, điều này có thể làm tăng đáng kể tải trên nhóm giao dịch L1
Nhóm giao dịch p2p mới cho mỗi L2— Một số giải pháp dọc theo dòng này có vẻ thuyết phục hơn. Người tìm kiếm/người xây dựng sẽ bắt đầu kiểm tra và diễn giải các giao dịch từ các nhóm giao dịch mới này bên cạnh các kênh thông thường của họ.
giảm thiểu MEV— Rollup có thể sử dụng một cách sáng tạo các biến thể khác nhau của FCFS, nhóm giao dịch được mã hóa, v.v.
xác nhận trước— Người dùng L2 thích "xác nhận" giao dịch nhanh. Các bản tổng hợp dựa trên chuỗi cơ sở sẽ quay trở lại tối đa thời gian khối L1 (12 giây) hoặc đợi lâu hơn để xuất bản một loạt giao dịch hoàn chỉnh.
Một bất lợi rõ ràng là Rollup dựa trên chuỗi cơ bản giới hạn tính linh hoạt của trình sắp xếp thứ tự. Ví dụ:
Thật thú vị, đây chính xác là những gì nhóm triển khai ban đầu đang xây dựng:
https://twitter.com/DZack 23/status/1635503593070657536? s= 20
Justin đã chỉ ra rằng việc đặt lại (retaking) có thể giúp ích.
https://twitter.com/jon_charb/status/1635898303106756609? s= 20
Đây là tất cả các lĩnh vực nghiên cứu của EigenLayer, ít nhất được đề cập trong sách trắng của họ. Không rõ liệu đây có phải là một giải pháp thiết thực hay không. Để cải thiện hiệu quả những thiếu sót này thông qua việc đặt lại, có thể hy vọng rằng tất cả những người đặt cược sẽ chọn chạy nó. Vì vậy, có vẻ hợp lý hơn khi triển khai ý tưởng theo cách này: hãy để một nhóm nhỏ những người đặt cược muốn làm như vậy chọn tham gia vào một lớp đặt hàng được chia sẻ riêng biệt (sẽ nói thêm về điều đó sau).
Bằng chứng về hiệu quả (PoE)
Năm ngoái, Polygon Hermez đã đưa ra một đề xuất có tên là PoE. Đây là một biến thể giải trình tự L1 khác dành riêng cho ZKR. Trình sắp xếp thứ tự ở đây là một vai trò hoàn toàn mở, bất kỳ ai cũng có thể gửi các lô giao dịch (tức là hoàn toàn vô chính phủ/tổng số dựa trên chuỗi cơ sở, vì vậy nó có các hạn chế tương tự). Cơ chế PoE bao gồm hai bước của hai bên:
trình sắp xếp thứ tự
Trình sắp xếp thứ tự thu thập các giao dịch của người dùng L2 và tạo một lô giao dịch bằng cách gửi một giao dịch L1 bao gồm dữ liệu từ tất cả các giao dịch L2 đã chọn. Trình sắp xếp thứ tự sẽ cam kết các khối dựa trên giá trị kinh tế nhận được hoặc cung cấp trải nghiệm ở cấp độ dịch vụ cho người dùng (ví dụ: xuất bản một loạt giao dịch trong mỗi khối L1, ngay cả khi điều này làm cho giao dịch L2 đắt hơn vì người dùng muốn giao dịch được hoàn thành nhanh hơn) .
tổng hợp
tổng hợp
Bộ tổng hợp ở đây được gọi là ZK-provers. Một lần nữa, đây là một vai trò không được phép và bất kỳ ai cũng có thể cạnh tranh. rất đơn giản:
Các lô đã sắp xếp mang dữ liệu giao dịch được sắp xếp trên L1 theo vị trí chúng xảy ra trên L1.
Hợp đồng thông minh PoE chấp nhận bằng chứng về tính hợp lệ đầu tiên được cập nhật sang trạng thái hợp lệ mới nhất, bao gồm một hoặc nhiều lô được đề xuất chưa được xác thực.
Người tổng hợp được tự do thực hiện phân tích lợi ích chi phí của riêng họ để tìm ra tần suất thích hợp để đưa ra bằng chứng. Nếu họ thắng trò chơi, họ sẽ nhận được một phần phí, nhưng nếu họ đợi lâu hơn để đưa ra bằng chứng mới, thì chi phí xác minh cố định của họ sẽ được phân bổ cho nhiều giao dịch hơn. Nếu trình tổng hợp gần đây xuất bản một bằng chứng (không chứng minh trạng thái mới), thì hợp đồng sẽ chỉ thực hiện chức năng đảo ngược. Prors lãng phí tính toán, nhưng chúng tiết kiệm hầu hết gas.
Phí được phân bổ như sau:
Phí cho các giao dịch L2 sẽ được xử lý và phân phối bởi các nhà tổng hợp, những người tạo ra bằng chứng về tính hợp lệ.
Tất cả các khoản phí giao dịch sẽ được gửi đến trình sắp xếp tương ứng cho mỗi đợt.
Phí do trình sắp xếp thứ tự ký gửi để có quyền tạo một lô duy nhất được gửi đến công cụ tổng hợp, bao gồm lô đó trong một bằng chứng về tính hợp lệ.
Quy tắc lựa chọn ngã ba thuần túy
Rollkit SR có một khái niệm rất giống về "quy tắc lựa chọn ngã ba thuần túy", như được mô tả ở đây, đề cập đến các bản tổng hợp tùy ý mà không có trình sắp xếp đặc quyền. Các nút được sắp xếp theo quy tắc của lớp DA và quy tắc lựa chọn ngã ba "đến trước được phục vụ trước" được áp dụng.
Kinh tế phân loại L1
Các thiết kế đặt hàng L1 này có ý nghĩa kinh tế quan trọng, vì MEV được tạo bởi các giao dịch L2 giờ đây sẽ được nắm bắt ở cấp nhà sản xuất khối L1. Trong mô hình đặt hàng L2 "truyền thống", MEV được tạo bởi các giao dịch L2 được thu thập bởi cơ chế đấu giá/người tham gia đồng thuận/trình sắp xếp thứ tự L2. Không rõ có bao nhiêu MEV rò rỉ vào lớp cơ sở trong trường hợp này.
Thật khó để nói đây là điều tốt hay điều xấu:
lợi ích— Điều này giống như một "liên minh kinh tế L1" (ví dụ: ETH có thể thu được nhiều giá trị hơn).
làm hại— Một số người sẽ lo lắng về ưu đãi lớp cơ sở này (ví dụ: rủi ro tập trung của các công cụ khai thác Bitcoin, nhưng có lẽ đã quá muộn).
tiêu đề cấp đầu tiên
Khuyến khích tạo ZK
Như một sự lạc đề ngắn gọn, lưu ý rằng thị trường cạnh tranh được mô tả ở trên trong PoE có thể trở nên tập trung xung quanh các bộ tổng hợp nhanh nhất. Nhìn chung, có hai vấn đề kinh tế cần giải quyết đối với thị trường chứng minh ZK:
Làm thế nào để khuyến khích người tục ngữ tạo ra bằng chứng này
Làm thế nào để gửi bằng chứng không được phép để nó trở thành một thị trường cạnh tranh và mạnh mẽ (ví dụ: nếu chứng minh chính ngừng hoạt động mà không ảnh hưởng đến mạng)
tiêu đề phụ
thị trường cạnh tranh
Ở một thái cực, bạn có thể có một chế độ cạnh tranh mở. Trong một thị trường chứng minh không được phép, tất cả các chứng minh cạnh tranh để tạo bằng chứng cho một khối được tạo bởi trình sắp xếp tổng số/sự đồng thuận. Người đầu tiên tạo ra bằng chứng sẽ nhận được bất kỳ phần thưởng nào được gán cho người chứng minh. Mô hình này rất hiệu quả trong việc tìm ra câu châm ngôn hay nhất.
Điều này trông rất giống với khai thác Proof of Work.Tuy nhiên, có một sự khác biệt duy nhất ở đây - bằng chứng là các phép tính xác định.Vì vậy, một người châm ngôn với một lợi thế nhỏ nhưng nhất quán sẽ gần như "luôn luôn" giành chiến thắng. Thị trường này có thể dễ dàng hình thành một tình huống tập trung.
Trong khai thác PoW, tính ngẫu nhiên có các thuộc tính tốt hơn - nếu tôi có 1% sức mạnh khai thác, tôi sẽ được thưởng 1%.
tiêu đề phụ
Các cơ chế dựa trên vòng quay (chẳng hạn như đặt trọng số)
Ngoài ra, một người có thể xoay vòng giữa những người chứng minh, tạo cơ hội cho mỗi người trong số họ (ví dụ: dựa trên một số cổ phần hoặc dựa trên danh tiếng). Điều này có thể phi tập trung hơn, nhưng có thể gây ra sự thiếu hiệu quả như chậm trễ trong việc chứng minh (một người chứng minh "chậm" sẽ có cơ hội tạo ra các bằng chứng, trong khi một người chứng minh khác có thể đã tạo ra các bằng chứng nhanh hơn và hiệu quả hơn). Tuy nhiên, nó tránh lãng phí tính toán bởi nhiều người chạy đua để tạo ra một bằng chứng, vì cuối cùng chỉ có một bằng chứng là hợp lệ.
Hơn nữa, nếu người đến lượt mình không đưa ra được bằng chứng (do cố ý hoặc vô tình), thì sẽ có vấn đề. Nếu các vòng đấu kéo dài (ví dụ: người chứng minh đến lượt vào thời điểm đó có thể độc quyền tạo ra bằng chứng trong nhiều giờ) và người chứng minh đi xuống, thì giao thức sẽ khó phục hồi. Nếu thời gian của vòng thi ngắn, những người chứng minh khác có thể tham gia và bắt kịp khi người chứng minh chính không đưa ra được bằng chứng.
Bạn cũng có thể cho phép bất kỳ ai xuất bản bằng chứng, nhưng chỉ những người chứng minh được chỉ định mới được thưởng trong một khoảng thời gian nhất định. Vì vậy, nếu những người chứng minh được chỉ định này không thành công, những người chứng minh khác có thể đưa ra những bằng chứng, nhưng họ sẽ không nhận được phần thưởng. Điều này sẽ mang tính vị tha, vì không có lợi ích gì cho việc tiêu tốn tài nguyên để tính toán.
Scroll đang khám phá nhiều cách tiếp cận dựa trên xoay vòng hơn, chỉ định các dấu vết thực thi cho các "con lăn" (provers) được chọn ngẫu nhiên:
Ngoài ra còn có nhiều câu hỏi thú vị về cách tính phí bằng chứng ở cấp độ người dùng khi phân loại. Thảo luận thêm về các chủ đề này có thể được tìm thấy ở đây:
- Ye Zhang của Scroll thảo luận về khả năng của một mạng con lăn luân phiên như vậy dựa trên đặt cược + đấu giá MEV để có quyền đặt hàng mà không yêu cầu sự đồng thuận của L2 trong bài viết "Zk-Rollup phi tập trung" của anh ấy
- "Tổng quan về Kiến trúc cuộn" cung cấp thêm chi tiết về mô hình con lăn khả thi
- Giao thức phi tập trung Starknet IV - Bằng chứng trong giao thức
tiêu đề cấp đầu tiên
sắp xếp chung
Hầu hết các giải pháp ban đầu đều giả định rằng mỗi lần tổng hợp sẽ cần tìm ra cách phân cấp hoàn toàn trình tự sắp xếp của chúng. Nhưng đây không phải là trường hợp, chẳng hạn như tùy chọn sắp xếp L1 đã đề cập ở trên. Nhiều bản tổng hợp có thể chọn sử dụng trình sắp xếp thứ tự được chia sẻ (SS, Trình sắp xếp thứ tự được chia sẻ). Điều này có một số lợi ích tuyệt vời:
nằm phẳng— Đừng lo lắng về cách phân cấp trình sắp xếp thứ tự của bạn, điều đó thật khó! Chỉ cần nhúng tùy chọn này. Không cần phải tuyển dụng và quản lý một nhóm nhỏ người xác nhận bổ sung. Mặc dù sẽ luôn có rất nhiều quảng cáo tài chính dưới danh nghĩa "mô-đun", đây thực sự là một cách tiếp cận rất "mô-đun" - loại bỏ thứ tự giao dịch thành một lớp riêng biệt. Trình tự chia sẻ (Shared Sequences) thực chất là một công ty SaaS (Sequencing as a Service).
Kết hợp bảo mật và phân quyền— Hãy để một lớp đặt hàng duy nhất xây dựng bảo mật kinh tế mạnh mẽ (xác nhận trước mạnh mẽ hơn) và khả năng chống kiểm duyệt theo thời gian thực, thay vì triển khai nhiều ủy ban nhỏ cho từng bản tổng hợp riêng lẻ.
Xác nhận giao dịch nhanh chóng— Các trình sắp xếp tổng số loại đơn khác cũng có thể thực hiện việc này, nhưng lưu ý rằng người dùng cũng nhận được xác nhận trước thời gian khối phụ L1 cực nhanh với thứ tự được chia sẻ.
Nguyên tử chuỗi chéo— Thực hiện đồng thời các giao dịch trên cả chuỗi A và chuỗi B (việc này phức tạp nên tôi sẽ tìm hiểu sâu hơn bên dưới).
Vẫn giới hạn ở dữ liệu L1 và thông lượng đặt hàng giao dịch
Mất khả năng cung cấp cho người dùng L2 xác nhận giao dịch nhanh hơn thời gian tạo khối của L1 (mặc dù có sự đảm bảo yếu hơn trước khi có sự đồng thuận cuối cùng của L1)
Chỉ cần sử dụng L1 cục bộ làm trình sắp xếp thứ tự cho nhiều L2 về cơ bản có một số nhược điểm:
Thứ tự L1 tốt nhất có thể làm là loại bỏ nút cổ chai tính toán của L1 (giả sử, nếu việc thực hiện giao dịch là nút cổ chai thông lượng) và đạt được một cải tiến nhỏ về độ phức tạp của giao tiếp.
tiêu đề phụ
Metro - Trình sắp xếp thứ tự được chia sẻ cho Astria
tiêu đề phụ
Thực hiện riêng biệt từ đặt hàng
Nút Tổng số hiện tại thực sự xử lý ba việc:
Thuộc tính chính ở đây là "tách thực thi và đặt hàng". Trình sắp xếp thứ tự được chia sẻ trong trường hợp này:
Giao dịch đặt hàng cho các chuỗi khác nhau chọn sử dụng nó làm lớp đặt hàng
không thực hiện (hoặc chứng minh)Các giao dịch này nhưng tạo ra trạng thái kết quả cho
Việc sắp xếp là không trạng thái - các nút trình sắp xếp thứ tự được chia sẻ không còn cần lưu trữ trạng thái đầy đủ cho tất cả các bản tổng hợp khác nhau. Họ loại bỏ các phép tính đang thực hiện. Các nút cổ chai lớn mà trình sắp xếp theo trình tự truyền thống hiện đang phải đối mặt không còn nữa.
Sự đồng thuận trở nên đặc biệt hiệu quả khi việc thực thi được tách rời khỏi sự đồng thuận. Quá trình này chỉ bị giới hạn trong lớp quảng bá thông tin (và do đó trở nên nhanh chóng). Các nút có thể rất hiệu quả nếu tất cả những gì chúng phải làm là tạo ra một khối giao dịch được sắp xếp theo thứ tự và đạt được sự đồng thuận trên khối đó mà không cần thực hiện tất cả các hoạt động. Việc thực thi và bằng chứng có thể được thực hiện bởi một bên khác sau khi đạt được sự đồng thuận của đơn đặt hàng.
Pooling Sequencer Bảo mật và phi tập trung
Các nút của trình sắp xếp thứ tự được chia sẻ có thể vẫn tương đối nhẹ và thậm chí mở rộng quy mô theo chiều ngang (bằng cách chọn một tập hợp con ngẫu nhiên các nút đồng thuận để sắp xếp các tập hợp con giao dịch khác nhau). Kết quả là - có khả năng làm cho lớp đặt hàng này trở nên phi tập trung hơn. Trình sắp xếp thứ tự truyền thống cần lưu trữ trạng thái lớn của chuỗi và thực hiện việc thực thi hoàn chỉnh của nó.
Ngoài ra, chúng tôi tập hợp các tài nguyên trên nhiều chuỗi - không cần phải phân chia sự đồng thuận của PoS giữa nhiều lần tổng hợp. Nhận tất cả chúng ở một nơi. Cách tiếp cận này có thể dẫn đến một tập hợp con trình tự sắp xếp phi tập trung hơn (chống kiểm duyệt) trên đó có nhiều giá trị có thể cắt giảm hơn so với nhiều bản tổng hợp triển khai tập hợp con trình tự sắp xếp riêng của chúng (chống tái tổ hợp). Điều này rất quan trọng bởi vì:
Đặt hàng — là tuyến phòng thủ đầu tiên để chống lại sự kiểm duyệt theo thời gian thực và tính sống động cho người dùng tổng hợp.
Thực thi và Chứng minh - có thể được thực hiện theo thứ tự mà không cần yêu cầu phân quyền mạnh mẽ. Tất cả những gì chúng ta cần là một bữa tiệc trung thực.
Đồng thuận mềm và đặt hàng — Trình sắp xếp thứ tự được chia sẻ cung cấp cho người dùng xác nhận trước nhanh chóng
Xác nhận đồng thuận và DA — dữ liệu giao dịch được hoàn thiện trên lớp DA để mọi người cùng xem
Dễ dàng thực hiện và bằng chứng — Bất kỳ ai cũng có thể thực hiện và tạo bằng chứng về trạng thái giao dịch đã xác nhận
Sau khi đạt được sự đồng thuận về thứ tự giao dịch, việc thực hiện (và bằng chứng) có thể bị trì hoãn sang một chuỗi hoàn toàn khác:
Công việc được thực hiện ở tầng điều hành không cần phải được phân cấp vì đây không phải là nguồn kháng cự kiểm duyệt. Trình sắp xếp nguyên khối không lý tưởng cho khả năng chống kiểm duyệt, nhưng nhược điểm của khả năng chống kiểm duyệt không liên quan gì đến luồng thực thi của trình sắp xếp. Sự kiểm duyệt của họ đến từ khả năng đặt hàng và đóng gói các giao dịch. Và ở lớp thực thi, trình sắp xếp thứ tự được chia sẻ đã cung cấp các đầu vào giao dịch được sắp xếp và do đó có khả năng chống kiểm duyệt. Sau đó, việc tính toán và so sánh các cam kết của nhà nước sau đó không cần phải được phân cấp như vậy.
thực hiện mềm
Bước đầu tiên để khớp lệnh mềm nhanh chóng là những gì người dùng ưa thích:
Điều này yêu cầu một số hình thức đồng thuận (hoặc trình sắp xếp tập trung) để cung cấp trải nghiệm người dùng tuyệt vời như vậy:
Nếu bạn chỉ dựa vào sự đồng thuận của một lớp cơ sở như Celestia, bạn không thể đảm bảo những lời hứa nhẹ nhàng này về việc đặt hàng và đóng gói rất tốt. Nếu lớp đặt hàng được chia sẻ có một ủy ban phi tập trung với một lượng lớn giá trị được đặt cược, nó có thể mang lại những lời hứa khá mạnh mẽ về việc tạo khối nhanh (thời gian khối phụ L1).
Do đó, khi một khối được tạo bởi trình sắp xếp chung, người dùng có thể nhận được xác nhận mềm. Bất kỳ ai cũng có thể tải xuống các giao dịch đồng thuận và áp dụng chúng cho trạng thái trước thời hạn. Sức mạnh của xác nhận này phụ thuộc vào việc xây dựng trình sắp xếp thứ tự được chia sẻ (phân cấp, bảo mật kinh tế, quy tắc lựa chọn ngã ba, v.v.). Các giao dịch này có thể được coi là đã hoàn tất sau khi dữ liệu thực sự được xuất bản lên lớp cơ sở. Tính toán cuối cùng của gốc trạng thái và bằng chứng liên quan sau đó có thể được tạo và gửi.
Tổng hợp Lười (Lazy Rollup)
"Lazy Rollup" rất đơn giản. Các bản tổng hợp này đợi cho đến khi tất cả các giao dịch của chúng được đặt hàng và xuất bản lên lớp DA, sau đó chúng có thể tải xuống các giao dịch đó, tùy ý áp dụng quy tắc lựa chọn rẽ nhánh để chọn một tập hợp con các giao dịch, thực hiện xử lý giao dịch và áp dụng các giao dịch đó cho trung tâm trạng thái. Sau đó, tiêu đề chuỗi khối có thể được tạo và phát.
Lưu ý rằng vì trình sắp xếp thứ tự được chia sẻ không thể tạo khối theo cách truy cập trạng thái hoàn chỉnh nên chúng không có chức năng kiểm tra các chuyển đổi trạng thái không hợp lệ. Do đó, một máy trạng thái sử dụng "rollup lười biếng" của trình sắp xếp thứ tự được chia sẻ phải có khả năng xử lý các giao dịch không hợp lệ. Các nút có thể chỉ cần xóa các giao dịch không hợp lệ/khôi phục khi thực hiện các giao dịch đã đặt hàng để tính toán trạng thái kết quả. Các bản tổng hợp truyền thống triển khai thực thi ngay lập tức không có giới hạn này.
Nếu quá trình tổng hợp yêu cầu quyền truy cập vào trạng thái để nén các giao dịch trước khi đóng gói chúng trên chuỗi, thì nó sẽ không hoạt động ở đây. Ví dụ: tổng số ở đây có quy tắc hợp lệ của khối trong đó tất cả các giao dịch có trong một khối đều hợp lệ. Nếu tổng số yêu cầu giao dịch nén, nhưng không có quyền truy cập trạng thái, thì có thể tạo một trình sắp xếp thứ tự được chia sẻ đặc biệt cho loại tổng số này (ví dụ: một cái gì đó như Fuel v2 hoặc tổng số có nhóm giao dịch riêng tư).
trả xăng
Để trình sắp xếp thứ tự được chia sẻ này hoạt động, phải có một số cơ chế để người dùng thanh toán cho các giao dịch của họ được đưa vào L1. Phí gas cho lớp đặt hàng được chia sẻ có thể được thanh toán chỉ bằng cách sử dụng chữ ký và địa chỉ hiện có đã được bao gồm trong hầu hết các loại giao dịch tổng số. Điều này sẽ yêu cầu trình sắp xếp thứ tự được chia sẻ nhận thức được trạng thái tối thiểu được yêu cầu bởi các triển khai khác nhau, ví dụ: phân tích cú pháp chữ ký, nonces, trừ gas khỏi tài khoản, v.v. triển khai. Ngoài ra, các khoản thanh toán có thể liên quan đến một số giao dịch được bao bọc trên trình sắp xếp thứ tự được chia sẻ, nơi bất kỳ ai cũng có thể thanh toán cho dữ liệu tùy ý được bao bọc. Đây là một không gian thiết kế mở.
Quy tắc lựa chọn ngã ba
Các bản tổng hợp có thể kế thừa các quy tắc lựa chọn rẽ nhánh của trình sắp xếp thứ tự được chia sẻ mà chúng sử dụng. Khi đó, các nút đầy đủ của quá trình tổng số thực sự là các ứng dụng khách nhẹ của trình sắp xếp thứ tự được chia sẻ, kiểm tra các cam kết nhất định để cho biết khối tổng số nào phù hợp với chiều cao khối nhất định.
Tuy nhiên, việc kế thừa các quy tắc lựa chọn rẽ nhánh của trình sắp xếp thứ tự được chia sẻ là tùy chọn - bạn có thể chỉ cần yêu cầu tổng số xử lý (không nhất thiết phải thực thi) tất cả dữ liệu giao dịch được gửi tới lớp cơ sở. Nó sẽ kế thừa một cách hiệu quả khả năng chống kiểm duyệt và tính sống động của lớp cơ sở, nhưng phải trả giá bằng nhiều tính năng của trình sắp xếp thứ tự được chia sẻ mà người dùng yêu thích.
MEV
Giả sử một tổng số muốn kế thừa các quy tắc lựa chọn rẽ nhánh của trình sắp xếp thứ tự được chia sẻ của nó và thực thi mềm nhanh chóng, trình sắp xếp thứ tự được chia sẻ này đương nhiên sẽ ở vị trí rất tập trung từ phía MEV. Nó xác định cách tổng số sẽ tôn trọng việc đóng gói và đặt hàng giao dịch.
Tuy nhiên, điều đó không có nghĩa là một tổng số phải thực hiện các giao dịch được cung cấp bởi trình sắp xếp thứ tự được chia sẻ hoặc theo thứ tự được cung cấp. Về mặt kỹ thuật, bạn có thể cho phép nhà điều hành tổng số của riêng mình thực hiện vòng xử lý thứ hai để sắp xếp lại các giao dịch do trình sắp xếp thứ tự được chia sẻ sau khi thực hiện. Tuy nhiên, như đã đề cập ở trên, bạn sẽ mất hầu hết các tính năng hay khi sử dụng trình sắp xếp thứ tự được chia sẻ ngay từ đầu, vì vậy điều này dường như khó xảy ra.
Ngay cả trong trường hợp này, MEV vẫn có thể tồn tại trong lớp đặt hàng được chia sẻ vì nó có quyền đóng gói các giao dịch. Nếu thực sự muốn, bạn thậm chí có thể cho phép tổng số của mình loại trừ một số giao dịch nhất định trong vòng xử lý thứ hai (ví dụ: sử dụng một số điều kiện hợp lệ để loại trừ một số loại giao dịch nhất định), nhưng điều này tất nhiên sẽ trở nên lộn xộn và giảm khả năng chống kiểm duyệt, và một lần nữa mất lợi ích của trình sắp xếp thứ tự được chia sẻ.
trao đổi trình tự chia sẻ
Điều khó phân tách trong chuỗi khối là bất kỳ hình thức chia sẻ trạng thái giá trị nào. Hãy xem một cái gì đó như ETH so với ETC hoặc tương tự ETH so với ETH POW, trong đó sự đồng thuận xã hội xác định đâu là "Ethereum thực". Trạng thái của "sự thật" mà tất cả chúng ta có thể đồng ý đều có giá trị.
Tuy nhiên, các trình sắp xếp thứ tự được chia sẻ thực sự chỉ là một nhà cung cấp dịch vụ - chúng không có trạng thái có giá trị nào được liên kết với chúng. Việc sử dụng tổng số cho một trình sắp xếp thứ tự được chia sẻ nhất định sẽ duy trì khả năng rẽ nhánh, chỉ yêu cầu một hard fork nhỏ hơn để chuyển sang hỗ trợ các cơ chế sắp xếp khác (ví dụ: khi trình sắp xếp thứ tự được chia sẻ trích xuất quá nhiều giá trị). Điều này hy vọng sẽ giữ cho các trình sắp xếp được chia sẻ có tính cạnh tranh.
tiêu đề phụ
Espresso Sequencer,ESQ — Bảo mật được đảm bảo bởi EigenLayer
Bạn có thể đã thấy sách trắng của EigenLayer đề cập đến các trình sắp xếp thứ tự được chia sẻ phi tập trung với tư cách là một trong những người tiêu dùng tiềm năng của việc đặt lại. Trình sắp xếp thứ tự được chia sẻ này có thể được bảo mật bởi các trình khôi phục ETH và nó có thể xử lý thứ tự giao dịch cho nhiều L2 khác nhau.
Chà, Espresso vừa công bố kế hoạch của họ cho một trình sắp xếp thứ tự được chia sẻ. Nó có thể sử dụng những người đặt lại EigenLayer để cung cấp bảo mật cho sự đồng thuận của nó. Để hình dung rõ hơn, đây là giao diện của tổng số hiện tại:
Sau đây là tổng số sẽ trông như thế nào với trình sắp xếp thứ tự được chia sẻ như Espresso:
Espresso Sequencer (ESQ) rất giống với Metro về ý tưởng chung. Nó hoạt động theo cùng một cách - tách việc thực hiện giao dịch khỏi việc đặt hàng. Ngoài ra, ESQ cũng sẽ cung cấp dữ liệu sẵn có cho các giao dịch.
Đồng thuận HotShot & Tính khả dụng của dữ liệu Espresso (DA)
Thông tin cơ bản ngắn gọn, Ethereum hiện đang sử dụng Gasper làm cơ chế đồng thuận (Casper FFG làm công cụ hoàn thiện + LMD GHOST làm quy tắc lựa chọn fork). Một vấn đề "quá dài để đọc" có liên quan là: Gasper duy trì tính sống động của mạng ngay cả trong các điều kiện bi quan khi phần lớn các nút có thể rời khỏi mạng (tính khả dụng động). Nó chạy hiệu quả hai giao thức (Casper FFG và LMD Ghost) cùng nhau duy trì một chuỗi động có sẵn với các tiền tố đã hoàn thiện. Nhưng trong khi duy trì tính sống động theo thời gian thực của mạng, Gasper hy sinh tính cuối cùng nhanh chóng của giao dịch (khả năng xác nhận giao dịch nhanh nhất mà mạng cho phép).
Nói chung, ESQ bao gồm:
HotShot —ESQ được xây dựng dựa trên giao thức đồng thuận HotShot, ưu tiên tính hoàn thiện nhanh (phản hồi lạc quan) hơn tính khả dụng động, không giống như Gasper. Nó cũng có thể mở rộng quy mô đến một số lượng đáng kinh ngạc các trình xác thực được hỗ trợ, như Ethereum.
Espresso DA — ESQ cũng cung cấp tùy chọn DA tùy chọn cho chuỗi. Cơ chế này cũng được sử dụng để mở rộng sự đồng thuận của họ.
Hợp đồng thông minh Sequencer— Hợp đồng thông minh này hoạt động như một ứng dụng khách nhẹ xác thực sự đồng thuận của HotShot và ghi lại các điểm kiểm tra (cam kết đối với các điểm trong nhật ký giao dịch được sắp xếp). Ngoài ra, nó chịu trách nhiệm quản lý những người đặt cược cho sự đồng thuận HotShot PoS của ESQ.
lớp mạng— Cho phép liên lạc các giao dịch và thông báo đồng thuận giữa các nút tham gia HotShot và Espresso DA.
Rollup REST API — API cuộn lên L2 để tích hợp với trình sắp xếp chuỗi Espresso.
Chúng ta hãy xem xét kỹ hơn về tình hình DA. Trong trường hợp lạc quan, các nút băng thông cao sẽ cung cấp dữ liệu cho tất cả các nút khác và tính khả dụng của từng khối riêng lẻ cũng được hỗ trợ bởi một ủy ban nhỏ được chọn ngẫu nhiên. Với nguy cơ bị tấn công DDoS và hối lộ chống lại các ủy ban nhỏ, Phân cấp thông tin có thể xác minh (VID) sẽ được sử dụng để cung cấp đường dẫn dự phòng đáng tin cậy (nhưng chậm hơn) để đảm bảo DA, miễn là tỷ lệ đủ cao của tất cả các nút (bằng Điện toán đặt cọc) không bị tấn công.
Quy trình giao dịch
Quy trình giao dịch
hợp đồng trình tự— HotShot tương tác trực tiếp với hợp đồng trình sắp xếp thứ tự L1 của nó. Hợp đồng này xác thực sự đồng thuận của HotShot và cung cấp giao diện cho những người tham gia khác xem các khối đã đặt hàng của nó. Hợp đồng lưu trữ nhật ký chỉ nối thêm các cam kết khối, không phải toàn bộ khối. Tuy nhiên, bất kỳ ai cũng có thể xác thực bất kỳ khối nào đối với một cam kết.
hợp đồng L2— Mỗi L2 sử dụng ESQ vẫn có hợp đồng cuộn Ethereum L1 của riêng mình. Để xác minh các bản cập nhật trạng thái được gửi tới từng bản cập nhật (thông qua tính hợp lệ/bằng chứng gian lận), mỗi hợp đồng bản tổng hợp phải có quyền truy cập vào chuỗi khối đã xác thực dẫn đến các bản cập nhật trạng thái xác định. Giao diện hợp đồng Rollup với hợp đồng trình sắp xếp thứ tự để truy vấn những thứ này.
Các giao dịch được chuyển tiếp tới trình sắp xếp thứ tự được chia sẻ được đặt hàng và sau đó được gửi lại cho người thực thi và trình kiểm chứng của bản tổng số trước khi được hoàn thiện trên L1. Trình sắp xếp thứ tự được chia sẻ cũng gửi một cam kết đối với khối tới hợp đồng trình sắp xếp thứ tự L1 của nó, cùng với chứng chỉ để xác thực khối. Điều này cho phép hợp đồng tổng số L1 so sánh các bằng chứng cập nhật trạng thái tổng số với các cam kết khối được chứng nhận là đầu ra đồng thuận.
tiêu đề phụ
Nguyên tử chuỗi chéo
Như đã đề cập trong bài viết về Espresso, trình sắp xếp thứ tự được chia sẻ có thể cung cấp một số trường hợp sử dụng thú vị liên quan đến tính nguyên tử của chuỗi chéo:
"Một lớp đặt hàng được chia sẻ trên nhiều đợt tổng hợp hứa hẹn sẽ làm cho việc nhắn tin và kết nối chuỗi chéo rẻ hơn, nhanh hơn và an toàn hơn. Việc không phải xây dựng ứng dụng khách nhẹ cho trình sắp xếp chuỗi của chuỗi khác là một lợi ích miễn phí, không mất phí, giúp tiết kiệm không gian tiềm năng được tạo trước. Kết nối qua các bản tổng hợp cũng có thể giúp tiết kiệm liên tục bằng cách loại bỏ nhu cầu về một bản tổng hợp nhất định để đồng bộ hóa độc lập sự đồng thuận của các bản tổng hợp khác. trong tổng số, nó chỉ xuất hiện nếu (thậm chí cùng lúc) nó được hoàn thiện trong một tổng số khác.
Ngoài ra, trình sắp xếp thứ tự được chia sẻ nâng cao khả năng của người dùng để thể hiện sự phụ thuộc nguyên tử giữa các giao dịch tổng số khác nhau. Thông thường, Alice ký và xuất bản giao dịch rollup-A t của cô ấy bên ngoài giao dịch rollup-B t' của Bob. Trong trường hợp này, giao dịch của Alice có thể được đặt trước rất lâu trước giao dịch của Bob, mang lại cho Bob tùy chọn hủy bỏ lâu (ví dụ: hủy bỏ giao dịch). Sự mất cân bằng tùy chọn này có thể được giảm thiểu bằng trình sắp xếp thứ tự được chia sẻ, trong đó Alice và Bob có thể gửi hai giao dịch cùng nhau dưới dạng một gói đã ký (nghĩa là trình sắp xếp thứ tự phải coi hai giao dịch là một). "
Điều này có ý nghĩa đối với MEV tên miền chéo khi hoạt động trên chuỗi cuối cùng cũng bắt đầu phát triển (tôi hy vọng). Một ví dụ điển hình là "chênh lệch giá nguyên tử". Cùng một tài sản giao dịch ở hai mức giá khác nhau trên hai chuỗi khác nhau. Người tìm kiếm hy vọng kiếm được lợi nhuận chênh lệch giá bằng cách thực hiện hai giao dịch cùng một lúc mà không có rủi ro thực hiện. Ví dụ:
Giao dịch 1 (T 1) — Mua ETH ở mức thấp trong đợt Rollup 1 (R 1)
Giao dịch 2 (T 2) — Bán ETH với giá cao trên Rollup 2 (R 2)
Để đạt được chênh lệch giá nguyên tử = cả hai giao dịch đều được thực hiện hoặc không giao dịch nào được thực hiện. Nó có thể đạt được chênh lệch giá nguyên tử này cho người tìm kiếm nếu cả hai bản tổng hợp chọn vào cùng một trình sắp xếp thứ tự được chia sẻ. Chia sẻ trình tự sắp xếp ở đây đảm bảo:
T 1 được đưa vào dòng lệnh tới R 1 khi và chỉ khi:
T 2 cũng được bao gồm trong dòng lệnh tới R 2
Giả sử rằng máy ảo tổng số thực hiện tuần tự tất cả các giao dịch trong các luồng tương ứng (nghĩa là không có hướng dẫn không hợp lệ, nhưng một số hướng dẫn có thể đưa ra lỗi nhưng không ảnh hưởng đến trạng thái), thì chúng tôi cũng có thể đảm bảo rằng:
T 1 thực hiện trên R 1 khi và chỉ khi:
T 2 cũng thực hiện trên R 2
Tuy nhiên, điều này vẫn không đảm bảo giống như thực hiện các giao dịch trên máy trạng thái dùng chung (ví dụ: hoàn toàn trên Ethereum L1). Như đã đề cập trước đó, trình sắp xếp thứ tự được chia sẻ không giữ trạng thái cho các bản tổng số này và chúng không thực hiện giao dịch. Do đó, không có gì đảm bảo hoàn toàn rằng một giao dịch (trên R 1 hoặc R 2 ) sẽ không bị khôi phục khi thực hiện.
Xây dựng các nguyên hàm cấp cao hơn trực tiếp trên đầu trang này là một vấn đề. Ví dụ: nếu cố gắng xây dựng chức năng bắc cầu chuỗi chéo "burn-mint" tức thì trên đầu trình sắp xếp thứ tự được chia sẻ này, chức năng này đồng thời thực hiện các thao tác sau ở cùng độ cao khối chính xác:
Đốt cháy một trong các đầu vào của R 1
Truyền đầu ra trên R2
Bạn có thể gặp những tình huống như thế này:
Hành vi phá hủy trên R 1 có thể gây ra lỗi không mong muốn, chẳng hạn như bị vô hiệu hóa bởi các giao dịch khác, nhưng
Hành động truyền trên R 2 sẽ không bị vô hiệu vì bất kỳ lý do gì, vì vậy nó sẽ được thực hiện đầy đủ.
Bạn có thể thấy những gì một vấn đề lớn này sẽ được.
Có thể có những trường hợp mà kết quả dự kiến của cả hai giao dịch có thể được xác định miễn là cả hai đều được đưa vào luồng đầu vào và do đó được thực thi, nhưng thường thì trường hợp này không xảy ra. Đó là một câu hỏi mở, quá trình này có thể:
đảm bảo— T 1 và T 2 sẽ được chứa trong các luồng riêng của chúng và (có thể) cả hai sẽ được thực thi.
không đảm bảo— Thực hiện thành công cả hai giao dịch và kết quả trạng thái dự kiến.
"Sự đảm bảo" này có thể đủ cho chênh lệch giá nguyên tử (trong đó người tìm kiếm đã sở hữu tài sản cần thiết để thực hiện các giao dịch này trên mỗi chuỗi), nhưng rõ ràng đó không phải là khả năng kết hợp đồng bộ của máy trạng thái dùng chung. Đối với những thứ như khoản vay chớp nhoáng liên chuỗi, bản thân sự đảm bảo này là không đủ.
Tuy nhiên, điều này vẫn có thể hữu ích trong các cài đặt khác khi được kết hợp với các giao thức nhắn tin chuỗi chéo khác. Hãy xem cách các giao dịch hoán đổi NFT nguyên tử chuỗi chéo có thể được hỗ trợ khi được sử dụng với giao thức nhắn tin cuộn lên chéo:
- T 1 chuyển ETH từ U 1 (Người dùng 1) sang SC 1 (Hợp đồng thông minh 1) trên R 1
- T 2 chuyển NFT từ U 2 (Người dùng 2) sang SC 2 (Hợp đồng thông minh 2) trên R 2
- Nó sẽ cho phép U 2 đổi ETH khi và chỉ khi SC 1 nhận được tin nhắn đầu tiên từ SC 2 xác nhận rằng NFT đã được ký gửi
- SC 2 sẽ cho phép U 1 đổi NFT khi và chỉ khi SC 2 nhận được tin nhắn đầu tiên từ SC 1 xác nhận rằng ETH đã được gửi
- Cả hai hợp đồng thông minh đều thực hiện khóa thời gian để nếu không thành công, tất cả các bên có thể lấy lại tài sản của mình
Trình sắp xếp thứ tự được chia sẻ ở đây cho phép hai người dùng thực hiện một cam kết nguyên tử ở bước 1. Sau đó, sử dụng một số hình thức nhắn tin cuộn lên chéo để xác minh trạng thái kết quả của nhau và mở khóa nội dung để thực hiện hoán đổi.
Nếu không có trình sắp xếp chung để biến nó thành nguyên tử, các bên có thể thỏa thuận về giá. Nhưng U1 có thể gửi giao dịch của họ và U2 có thể đợi và quyết định xem họ có muốn hủy bỏ giao dịch hay không. Với một trình sắp xếp được chia sẻ, các giao dịch của họ bị khóa.
Đó là tất cả những gì có về tính nguyên tử chuỗi chéo mà trình sắp xếp thứ tự được chia sẻ đạt được. tóm tắt:
Sức mạnh và tính hữu ích chính xác của các đảm bảo được cung cấp ở đây vẫn chưa được chứng minh
Điều này có thể rất hữu ích cho chênh lệch giá nguyên tử chuỗi chéo, cũng như các
IOS
Android