Trình sắp xếp được chia sẻ cho chuỗi ứng dụng Starknet và Madara

Giới thiệu loại coin

Ngày nay, chúng ta đã thấy các dự án bắt đầu thử nghiệm Madara cho chuỗi ứng dụng của họ. Pragma, Kakarot, Mangata Finance và Dojo chỉ là một số ví dụ. Miễn là chúng tôi tin tưởng vào tương lai đa chuỗi và sức mạnh của việc mở rộng quy mô zk, chúng tôi sẽ chỉ thấy nhiều dự án như vậy nữa trong tương lai. Tuy nhiên, số lượng chuỗi ứng dụng ngày càng tăng cũng đặt ra câu hỏi xung quanh

1. Phân cấp
2. Khả năng kết hợp
3. Kinh nghiệm phát triển

Trong bài đăng này, tôi sẽ cố gắng giải thích các vấn đề phát sinh do có nhiều chuỗi ứng dụng, đồng thời đưa ra giải pháp khả thi cho vấn đề mà tôi cho là hợp lý và tối ưu cho Madara và Starknet. Nếu bạn đã thành thạo với chuỗi ứng dụng và trình tự chia sẻ, vui lòng chuyển sang phần “Đợi đã, lại chỉ là Polkadot thôi”.

Điều gì xảy ra ở 100 chuỗi ứng dụng?

Giả sử chúng ta đang ở trong một tương lai nơi chúng ta hiện có 100 chuỗi ứng dụng khác nhau hoạt động trên Ethereum. Hãy giải quyết tất cả các vấn đề mà điều này sẽ gây ra.

Phân cấp rời rạc

Mỗi chuỗi ứng dụng sẽ cần phải tự giải quyết vấn đề phân cấp. Giờ đây, việc phân cấp chuỗi ứng dụng không còn cần thiết như L1, chủ yếu vì chúng tôi dựa vào L1 để bảo mật. Tuy nhiên, chúng ta vẫn cần phân cấp để đảm bảo tính sinh động, chống kiểm duyệt và tránh lợi thế độc quyền (ví dụ phí cao). Tuy nhiên, điều quan trọng cần lưu ý là nếu mỗi chuỗi ứng dụng tiếp tục giải quyết vấn đề phân cấp theo cách riêng của mình, điều này sẽ rất nhanh chóng dẫn đến sự phân mảnh của các bộ trình xác thực. Mỗi chuỗi ứng dụng sẽ phải phát triển các biện pháp khuyến khích kinh tế để tích hợp các trình xác thực mới. Ngoài ra, người xác thực sẽ cần chọn những ứng dụng khách mà họ cảm thấy thoải mái khi chạy. Chưa kể đến rào cản gia nhập rất lớn, điều này tạo ra cho các nhà phát triển khởi chạy chuỗi ứng dụng của riêng họ (so với việc triển khai hợp đồng thông minh vốn chỉ là một giao dịch).

Khả năng kết hợp

Khả năng kết hợp về cơ bản có nghĩa là tương tác giữa các ứng dụng. Trên Ethereum hoặc Starknet, điều này chỉ có nghĩa là gọi một hợp đồng khác và mọi thứ khác sẽ được xử lý bởi chính giao thức đó. Tuy nhiên, với chuỗi ứng dụng, việc này trở nên khó khăn hơn rất nhiều. Các chuỗi ứng dụng khác nhau có các khối và cơ chế đồng thuận riêng. Mỗi khi cố gắng tương tác với một chuỗi ứng dụng khác, bạn cần phải kiểm tra cẩn thận thuật toán đồng thuận và các đảm bảo về tính hữu hạn, từ đó thiết lập một cầu nối chuỗi chéo (trực tiếp đến chuỗi hoặc thông qua L1). Nếu bạn muốn tương tác với 10 chuỗi ứng dụng có thiết kế khác nhau, bạn sẽ thực hiện việc này 10 lần khác nhau.

Kinh nghiệm phát triển

Giải quyết vấn đề phân quyền và bắc cầu không hề dễ dàng. Nếu đây là yêu cầu đối với mọi chuỗi ứng dụng, nó sẽ gây khó khăn cho nhà phát triển hợp đồng thông minh thông thường trong việc xây dựng chuỗi ứng dụng của riêng mình. Hơn nữa, khi mỗi chuỗi ứng dụng cố gắng giải quyết những vấn đề này theo cách riêng của mình, chúng ta sẽ sớm thấy các tiêu chuẩn khác nhau được các chuỗi khác nhau tuân theo, khiến việc tham gia hệ sinh thái càng trở nên khó khăn hơn.

Trình sắp xếp được chia sẻ có thể giải quyết vấn đề này

Bây giờ, nếu bạn đang theo dõi không gian chuỗi ứng dụng, bạn có thể đã nghe nói đến thuật ngữ “trình sắp xếp được chia sẻ”. Đó là ý tưởng có một bộ trình xác nhận chung cho tất cả các chuỗi nhằm giải quyết các vấn đề nêu trên. Đây là cách nó hoạt động.

Phân quyền chia sẻ

Bản chất của trình tuần tự được chia sẻ là bạn không cần phải có bộ trình xác thực khác nhau cho mỗi chuỗi ứng dụng hoặc L2. Thay vào đó, bạn có thể có một bộ trình xác thực thực sự hiệu quả và phi tập trung để sắp xếp các khối cho tất cả các chuỗi! Hãy tưởng tượng các khối chứa giao dịch từ 100 chuỗi ứng dụng khác nhau. Bạn có thể nghĩ rằng điều này sẽ thực sự làm phức tạp trình sắp xếp thứ tự vì bạn cần có khả năng xử lý các công cụ thực thi cho từng chuỗi ứng dụng.

Vâng, bạn không!

Vì ngày nay hầu hết mọi trình sắp xếp đều được tập trung hóa nên trình sắp xếp được coi là một ứng dụng duy nhất thu thập các giao dịch, ra lệnh cho chúng, thực hiện chúng và đăng kết quả lên L1. Tuy nhiên, những công việc này có thể được tách thành nhiều thành phần mô-đun. Để giải thích điều này, tôi sẽ chia chúng thành hai.

1. Công cụ đặt hàng: Công cụ này chịu trách nhiệm sắp xếp thứ tự các giao dịch theo một thứ tự cụ thể. Khi lệnh này đã được quyết định bởi công cụ đặt lệnh, nó PHẢI được tuân theo. Điều này được thực thi bằng cách thực hiện lệnh này trên L1 và buộc người xác minh L1 kiểm tra xem các giao dịch có được thực hiện theo thứ tự được yêu cầu hay không.
2. Công cụ tổng hợp: Công cụ tổng hợp về cơ bản là mọi thứ khác mà công cụ tổng hợp thực hiện - thu thập các giao dịch từ người dùng, thực hiện chúng, tạo bằng chứng và cập nhật trạng thái trên L1. Lý tưởng nhất là điều này có thể được chia thành nhiều thành phần hơn nhưng chúng tôi sẽ tránh điều đó đối với bài đăng này.

Ở đây, công cụ đặt hàng là trình sắp xếp được chia sẻ và công cụ tổng hợp về cơ bản là logic tổng hợp. Vì vậy, vòng đời giao dịch trông như thế này

Về cơ bản, các trình sắp xếp được chia sẻ sẽ sắp xếp các giao dịch qua các lần tổng hợp và cam kết chúng với L1. Do đó, bằng cách phân quyền bộ trình tự chia sẻ, về cơ bản bạn đã phân cấp tất cả các bản tổng hợp được liên kết với bộ trình tự sắp xếp đó! Để có ý tưởng chi tiết hơn về hoạt động của trình sắp xếp được chia sẻ, bạn cũng có thể tham khảo <a href="https://hackmd.io/@EspressoSystems/EspressoSequencer"> bài viết 17 tuyệt vời này của Espresso.

Khả năng kết hợp

Một trong những vấn đề chính của khả năng kết hợp là hiểu được thời điểm giao dịch được hoàn tất trên chuỗi ứng dụng khác và từ đó thực hiện các hành động trên chuỗi của bạn. Nhưng với các trình sắp xếp được chia sẻ, cả hai bản tổng hợp có thể kết hợp đều chia sẻ các khối với nhau. Vì vậy, nếu một giao dịch được khôi phục trên bản tổng hợp B, thì toàn bộ khối sẽ được khôi phục và điều này khiến giao dịch trên bản tổng hợp A cũng được hoàn nguyên.

Bây giờ điều này chắc chắn nói dễ hơn làm. Vì điều này. giao tiếp giữa các bản tổng hợp cần phải hiệu quả và có thể mở rộng. Các trình sắp xếp được chia sẻ cần phải đưa ra các tiêu chuẩn phù hợp về cách các bản tổng hợp có thể giao tiếp, các thông báo chuỗi chéo sẽ trông như thế nào, cách xử lý các bản nâng cấp tổng hợp, v.v. Mặc dù đây là những vấn đề có thể giải quyết được nhưng chúng rất phức tạp và không dễ giải quyết.

Kinh nghiệm của nhà phát triển

Mặc dù trình sắp xếp chuỗi được chia sẻ trừu tượng hóa khía cạnh phân cấp và làm cho việc nhắn tin giữa các chuỗi trở nên dễ dàng hơn, nhưng vẫn có một số tiêu chuẩn mà mọi chuỗi cần tuân theo để tương thích với trình sắp xếp được chia sẻ. Ví dụ: tất cả giao dịch tổng hợp cần phải được chuyển đổi thành định dạng chung mà trình sắp xếp chuỗi có thể hiểu được. Tương tự, các khối từ trình sắp xếp thứ tự cần được lọc để tìm nạp các giao dịch có liên quan. Để giải quyết vấn đề này, tôi cho rằng các trình sắp xếp được chia sẻ sẽ đưa ra các khung tổng hợp hoặc SDK trừu tượng hóa mã soạn sẵn và chỉ hiển thị phần logic nghiệp vụ cho các nhà phát triển chuỗi ứng dụng.

Đây là sơ đồ về cách các chuỗi ứng dụng sẽ trông như thế nào với các trình sắp xếp được chia sẻ

Đợi đã, lại toàn là Polkadot thôi

Polkadot bắt đầu nghiên cứu về tương lai đa chuỗi trước Ethereum rất nhiều. Trên thực tế, họ đã nghiên cứu nó được hơn 5 năm và nếu bạn quen thuộc với Polkadot, bạn có thể nhận thấy rằng thiết kế trên về cơ bản là phát minh lại rất nhiều thứ mà Polkadot đã làm!

Chuỗi chuyển tiếp (Phân cấp chung)

Chuỗi Rơle về cơ bản là công cụ đặt hàng + L1 trong sơ đồ trình tự trên. Chuỗi tiếp sức

1. Đặt hàng các giao dịch trên tất cả các parachains (rollups)
2. Nó xác minh các giao dịch được thực hiện chính xác (thay vì xác minh zk, nó thực sự chạy lại mã thực thi của bản tổng hợp để xác minh các khác biệt trạng thái)

Bạn có thể đã nhận ra rơle về cơ bản là bộ tuần tự được chia sẻ mà chúng ta đã thảo luận ở trên. Ngoại trừ thực tế là chuỗi chuyển tiếp cũng cần xác minh việc thực thi (vì Polkadot là L1) trong khi chúng tôi để việc đó cho Ethereum.

XCM và XCMP

Chúng tôi đã đề cập ở phần trước rằng nếu mỗi chuỗi xây dựng các phương pháp riêng để tương tác với các chuỗi khác, thì chúng tôi sẽ sớm có đầy đủ các tiêu chuẩn và định dạng khác nhau trên tất cả các chuỗi. Bạn sẽ cần theo dõi tất cả các định dạng này cho mọi chuỗi mà bạn tương tác. Hơn nữa, bạn cũng sẽ cần trả lời các câu hỏi như điều gì sẽ xảy ra nếu chuỗi nâng cấp? Tuy nhiên, những vấn đề này có thể được giải quyết một cách khéo léo bằng cách đưa ra các tiêu chuẩn mà tất cả các chuỗi phải tuân theo.

Như bạn có thể đoán, Polkadot đã làm được điều này. XCM là định dạng nhắn tin và XCMP là giao thức nhắn tin mà tất cả các chuỗi cơ chất có thể sử dụng để liên lạc với nhau. Tôi sẽ không đi sâu vào chi tiết nhưng bạn có thể đọc về nó ở đây 5.

Chất nền và tích lũy

Chất nền là một khung được phát triển bởi Parity có thể được sử dụng để xây dựng chuỗi khối. Mặc dù tất cả các parachain trên Polkadot đều sử dụng chất nền, nhưng chất nền thực sự được xây dựng theo cách bất khả tri về chuỗi. Khung tóm tắt tất cả các khía cạnh chung của blockchain để bạn chỉ có thể tập trung vào logic ứng dụng của mình. Như chúng ta đã biết, Madara được xây dựng trên Substrate và Polkadot, Polygon Avail và nhiều dự án khác cũng vậy. Hơn nữa, Cumulus là một phần mềm trung gian trên Substrate cho phép bạn kết nối chuỗi của mình với Polkadot.

Vì vậy, tiếp tục sự tương tự của chúng ta như trước đây, Substrate và Cumulus có thể được coi là những sản phẩm thay thế cho các khung tổng hợp cho phép bạn xây dựng chuỗi ứng dụng và kết nối chúng với các trình sắp xếp được chia sẻ.

Trình tự chia sẻ → Chuỗi chuyển tiếp
Khả năng kết hợp → XCM và XCMP
Khung cuộn/Ngăn xếp → Chất nền và Tích lũy

Vì vậy, vâng, lại gần như là Polkadot! Ngoài ra, Polkadot và Parity còn có một số nhóm giàu kinh nghiệm và được tài trợ nhất đang tiếp tục xây dựng Substrate và Polkadot để bổ sung thêm nhiều tính năng hơn và làm cho nó có khả năng mở rộng cao hơn. Công nghệ này đã được thử nghiệm trong nhiều năm và có rất nhiều công cụ dành cho nhà phát triển.

Giải quyết Polkadot trên Ethereum?

Mặc dù đúng là Polkadot đã bắt đầu xây dựng tương lai đa chuỗi trước Ethereum, nhưng không thể phủ nhận rằng tính đến ngày hôm nay, Ethereum là blockchain phi tập trung nhất và là nơi tập trung hầu hết các ứng dụng và tính thanh khoản. Tuy nhiên, điều gì sẽ xảy ra nếu có cách đưa tất cả công nghệ Polkadot vào hệ sinh thái Ethereum?

Có! Trên thực tế, chúng tôi đã bắt đầu việc này với Madara. Madara sử dụng khung Substrate để cho phép mọi người xây dựng giải pháp L2/L3 do zk cung cấp của riêng họ trên Ethereum. Thứ chúng ta cần tiếp theo là chuỗi chuyển tiếp Polkadot ở dạng trình tự chia sẻ. Về cơ bản, nếu chúng ta có thể tái sử dụng chuỗi chuyển tiếp Polkadot nhưng

1. Xóa phần xác minh như xảy ra trên L1 thông qua bằng chứng zk
2. Cam kết thứ tự giao dịch với L1
3. Tối ưu hóa các nút và thuật toán đồng thuận để hỗ trợ Tendermint/HotStuff

Chúng ta có thể nhận được các trình sắp xếp được chia sẻ như đã đề cập trước đó. Rõ ràng, điều này nói dễ hơn làm. Tuy nhiên, tôi tin rằng con đường này thực dụng hơn là xây dựng lại trình tự, tiêu chuẩn và khuôn khổ từ đầu. Polkadot đã giải quyết được rất nhiều vấn đề theo cách bất khả tri về chuỗi mà chúng ta có thể vay cho Ethereum. Là một sản phẩm phụ, chúng tôi nhận được

1. Một nhóm các nhà phát triển tích cực tiếp tục xây dựng và giáo dục thế giới về Substrate
2. Bộ công cụ dành cho nhà phát triển đang hoạt động và cộng đồng mạnh mẽ
3. Rất nhiều parachain đang hoạt động cũng có thể chọn giải quyết trên Ethereum nếu họ muốn làm như vậy (gần đây chúng tôi đã thấy Astar làm điều tương tự với Polygon CDK)

Phần kết luận

Ý tưởng chính của tôi khi viết bài này là mở ra cuộc thảo luận giữa hệ sinh thái rộng lớn hơn của Starknet và Ethereum. Tôi cảm thấy mô hình trình tự được chia sẻ sẽ đóng một vai trò quan trọng trong việc phân quyền không chỉ của Starknet mà còn của tất cả các chuỗi ứng dụng đang xem xét xây dựng trên đó. Miễn là chúng tôi tự tin về luận điểm chuỗi ứng dụng và tỷ lệ zk, thì việc phân tích kỹ lưỡng mô hình giải trình tự được chia sẻ là điều không thể tránh khỏi. Hơn nữa, khi Madara đang tiến tới sản xuất và Starknet đã bắt đầu công việc phân cấp, tôi cảm thấy chủ đề này hiện rất quan trọng để giải quyết. Do đó, tôi yêu cầu mọi người đọc bài này để lại bất kỳ phản hồi/đề xuất nào bạn có về chủ đề này. Mong được đọc suy nghĩ của bạn!

ruột thừa

Polkadot vs vũ trụ

Cosmos, tương tự như Polkadot, đã giải quyết một tương lai đa chuỗi trong nhiều năm nay. Kết quả là, nó đã đạt được nhiều bước phát triển với Cosmos SDK và IBC, đồng thời chúng tôi cũng thấy rất nhiều chuỗi ứng dụng được xây dựng trên hệ sinh thái Cosmos. Do đó, thật công bằng khi xem xét Cosmos cho cách tiếp cận này. Quan điểm cá nhân của tôi về chủ đề này là Polkadot phù hợp hơn vì nó giải quyết được vấn đề về trình xác thực được chia sẻ trong khi Cosmos yêu cầu mỗi chuỗi ứng dụng xây dựng bộ trình xác thực của riêng mình. Hơn nữa, Substrate luôn được xây dựng theo cách bất khả tri về chuỗi để cho phép các nhà phát triển xây dựng chuỗi khối mà không cần giả định về thuật toán đồng thuận hoặc hệ sinh thái Polkadot. Đây cũng là lý do tại sao chúng tôi chọn Chất nền cho Madara. Tuy nhiên, như đã nói, trải nghiệm của tôi trên Cosmos còn hạn chế và tôi rất muốn nghe thêm về vấn đề này từ những người có kinh nghiệm hơn! Bạn cũng có thể tìm hiểu thêm về so sánh hai mạng tại đây

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [starknet]. Mọi bản quyền đều thuộc về tác giả gốc [apoorvsadana]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch 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 đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.