原标题: Tôi đã học cách ngừng lo lắng và chia sẻ tình yêu như thế nào
Liên kêt video:
Diễn giả: Scott Sunarto (@smsunarto) trong Ngày Nghiên cứu
Biên tập và hoàn thiện bài viết: Justin Zhao (@hiCaptainZ)
Xin chào, tôi là Scott (@smsunarto), người sáng lập August Labs (@ArgusLabs_). Hôm nay, tôi sẽ nói về một chủ đề mà chúng ta đã không đề cập đến trong một thời gian. Với việc tổng hợp trở thành xu hướng chủ đạo của thời đại, chúng tôi không thảo luận nhiều về việc bảo vệ quá trình thực thi mà chúng tôi thảo luận về việc bảo vệ dữ liệu. Vì vậy, hãy xem lại chủ đề hơi bị bỏ quên này - phân đoạn thực thi.
Đây sẽ là một cuộc trò chuyện dễ dàng. Tôi biết bạn đã nghe các khái niệm phức tạp cả ngày, vì vậy tôi sẽ cố gắng làm cho cuộc thảo luận này thực tế nhất có thể. Tôi đã chuẩn bị một thiết kế slide phù hợp cho bài thuyết trình này.
Đối với những người không biết tôi, điều buồn cười là, tôi được biết đến trên Twitter với tư cách là một cô gái anime. Tôi cũng đã trượt lễ tốt nghiệp đại học chỉ để đến đây, khiến cha mẹ tôi vô cùng thất vọng. Hiện tại, tôi là người sáng lập Argus Labs. Chúng tôi coi mình là một công ty trò chơi, không phải là một công ty cơ sở hạ tầng hoặc tiền điện tử. Một trong những mối quan tâm lớn nhất của tôi là mọi người chơi trò chơi tiền điện tử đều muốn xây dựng các công cụ, nhưng không ai muốn tạo nội dung hoặc ứng dụng. Chúng tôi cần nhiều ứng dụng hơn mà người dùng thực sự có thể sử dụng.
Trước đây, tôi đã đồng sáng tạo Dark Forest (@darkforest_eth) cùng với những người bạn thông minh của mình là Brian Gu (@gubsheep) và Alan Luo (@alanluo_0). Brian hiện đang chạy 0xPARC (@0xPARC) và anh ấy thông minh hơn tôi rất nhiều.
Cuộc thảo luận hôm nay sẽ tập trung vào việc thực hiện phân đoạn, nhưng trong bối cảnh hầu hết mọi người không quen thảo luận về việc thực hiện phân đoạn. Chúng tôi thường thảo luận về phân đoạn thực thi trong bối cảnh Lớp 1, chẳng hạn như phân đoạn Ethereum hoặc phân đoạn Gần. Nhưng hôm nay, tôi muốn thay đổi bối cảnh một chút. Hãy nghĩ về việc shending sẽ trông như thế nào trong môi trường cuộn lên.
Câu hỏi cơ bản ở đây là tại sao một công ty trò chơi lại xây dựng danh sách tổng hợp của riêng mình và chúng ta có thể học được gì từ World of Warcraft để thiết kế danh sách tổng hợp. Ngoài ra, chúng ta sẽ khám phá cách không gian thiết kế cho cuộn lên vượt xa thực tế hiện tại.
Để trả lời những câu hỏi này, chúng ta hãy quay trở lại năm 2020, khi ý tưởng về Khu rừng tối lần đầu tiên được hình thành. Chúng tôi tự hỏi, điều gì sẽ xảy ra nếu chúng tôi tạo ra một trò chơi trong đó mọi hành động trong trò chơi là một giao dịch trực tuyến? Tiền đề lúc đó thật lố bịch, và nó vẫn còn đối với nhiều người ngày nay. Nhưng đó là một giả thuyết thú vị, vì vậy chúng tôi đã xây dựng nó, và Dark Forest ra đời.
Dark Forest là một trò chơi MMORTS khám phá không gian toàn chuỗi hoàn toàn dựa trên Ethereum, được cung cấp bởi ZK-Snarks. Trở lại năm 2020, ZK không phổ biến như ngày nay vì hầu như không có bất kỳ tài liệu nào. Tài liệu hiện có duy nhất cho Circcom là Google Docs của Jordi Baylina (@jbaylina). Bất chấp những thách thức, chúng tôi đã học được rất nhiều điều trong suốt chặng đường và Dark Forest là hiện thân của những bài học đó.
Dark Forest là một thử nghiệm lớn hơn chúng ta tưởng. Chúng tôi có hơn 10.000 người chơi, hàng nghìn tỷ gas đã tiêu tốn, sự hỗn loạn trong trò chơi, mọi người đâm sau lưng trên dây chuyền. Điều hấp dẫn nhất về Dark Forest và trò chơi trực tuyến là bản chất nền tảng. Bằng cách có một trò chơi toàn chuỗi, bạn mở ra cánh cửa cho một không gian thiết kế cho các hành vi mới nổi, cho phép mọi người xây dựng các hợp đồng thông minh tương tác với trò chơi, cũng như các ứng dụng khách và chế độ trò chơi thay thế, chẳng hạn như Dark Forest Arena và công cụ khai thác GPU.
Tuy nhiên, với sức mạnh lớn đi kèm với trách nhiệm lớn. Khi chúng tôi ra mắt Dark Forest trên xDai, hiện được gọi là Gnosis Chain, cuối cùng chúng tôi đã lấp đầy toàn bộ không gian khối của chuỗi. Điều này làm cho chuỗi về cơ bản không thể sử dụng được cho bất kỳ thứ gì khác, bao gồm DeFi, NFT hoặc bất kỳ thứ xDAI nào khác.
Giờ thì sao? Chúng ta đã đi đến ngõ cụt chưa? Các trò chơi toàn chuỗi sẽ không bao giờ trở thành hiện thực? Hay chúng ta sẽ quay lại làm những trò chơi chỉ có những hình ảnh JPEG nhỏ được lưu trữ trên chuỗi và thuyết phục mọi người rằng tiền sinh sôi nảy nở? Câu trả lời là, chúng tôi để phần mềm làm mọi việc. Nhiều người trong chúng ta có quan điểm rất cứng nhắc về blockchain và roll-up, như thể không có nhiều chỗ để cải thiện. Nhưng tôi không đồng ý. Chúng ta có thể thử nghiệm và tìm ra những khả năng mới.
Chúng tôi đã tự hỏi mình một câu hỏi: nếu chúng tôi thiết kế một chuỗi khối từ đầu cho trò chơi và chỉ trò chơi, thì nó sẽ trông như thế nào? Chúng tôi cần thông lượng cao, vì vậy chúng tôi cần mở rộng quy mô đọc và ghi. Hầu hết các chuỗi khối được thiết kế để ghi nhiều. Số giao dịch mỗi giây (TPS) là một số liệu mà mọi người khoe khoang, nhưng trên thực tế, số lần đọc cũng quan trọng không kém. Làm thế nào để bạn biết vị trí của người chơi nếu bạn không thể đọc từ nút chuỗi khối? Đây thực sự là nút cổ chai đầu tiên mà chúng tôi tìm thấy trong quá trình xây dựng chuỗi khối.
Dark Forest gặp sự cố khi các nút đầy đủ được sử dụng nhiều và I/O bùng nổ vì chúng tôi cần đọc dữ liệu từ trạng thái trên chuỗi. Điều này dẫn đến chi phí máy chủ lên tới hàng nghìn đô la, được nhóm xDAI hào phóng chi trả cho chúng tôi. Tuy nhiên, điều này không lý tưởng cho dài hạn. Chúng tôi cần thông lượng cao, không chỉ cho các giao dịch được viết mỗi giây mà còn cho các lần đọc, chẳng hạn như tìm nạp dữ liệu từ chính chuỗi khối.
Chúng tôi cũng cần một chuỗi khối có thể mở rộng theo chiều ngang để tránh vấn đề Hàng xóm ồn ào. Chúng tôi không muốn một trò chơi phổ biến đột nhiên bắt đầu gặp sự cố trên chuỗi khối, dừng mọi hoạt động. Chúng tôi cũng cần tính linh hoạt và khả năng tùy chỉnh để có thể sửa đổi máy trạng thái được thiết kế cho trò chơi. Điều này bao gồm việc có vòng lặp trò chơi, làm cho trò chơi tự thực hiện, v.v.
Cuối cùng nhưng không kém phần quan trọng, đối với những người không quen thuộc với kiến trúc của trò chơi trực tuyến, điều này có thể hơi mơ hồ, chúng tôi cần tỷ lệ đánh dấu cao. Bọ ve là đơn vị thời gian nguyên tử trong thế giới trò chơi. Trong ngữ cảnh của chuỗi khối, chúng ta có các khối dưới dạng đơn vị thời gian nguyên tử. Trong các trò chơi, chúng tôi có bọ ve. Điều này gần như tương tự khi bạn xây dựng một trò chơi toàn chuỗi, trong đó tốc độ tạo khối hoặc đánh dấu của chuỗi khối của bạn bằng với tốc độ đánh dấu của chính trò chơi đó.
Do đó, những gì chúng ta cần là một chuỗi khối có thông lượng cao, khả năng mở rộng theo chiều ngang, tính linh hoạt và tùy biến cũng như tỷ lệ đánh dấu cao. Thiết kế như vậy có thể đáp ứng nhu cầu của chuỗi khối mà chúng tôi đã thiết kế từ đầu cho trò chơi.
Nếu bạn có tỷ lệ đánh dấu cao hơn hoặc nhiều khối hơn mỗi giây, trò chơi sẽ phản hồi nhanh hơn. Ngược lại, nếu tỷ lệ đánh dấu của bạn thấp, trò chơi sẽ cảm thấy chậm chạp. Một điều quan trọng cần nhớ là nếu các khối bị trì hoãn, bạn sẽ gặp phải tình trạng trễ đáng kể trong trò chơi. Đây là một kinh nghiệm tồi tệ. Nếu bạn đã từng đối phó với những người chơi tức giận hét vào mặt máy tính vì thua một trò chơi, thì đó thực sự là một tình huống tồi tệ.
Hiện tại, các bản tổng hợp của chúng tôi có một khối mỗi giây, tương đương với một lần đánh dấu. Nếu chúng tôi muốn có những trò chơi thú vị hơn, chúng tôi cần tỷ lệ đánh dấu cao hơn. Ví dụ: Minecraft, một trò chơi nghệ thuật pixel đơn giản, có 26 tích tắc mỗi giây. Chúng tôi vẫn còn một chặng đường dài để xây dựng một trò chơi phản ứng nhanh như Minecraft.
Một giải pháp khả thi là triển khai bản tổng hợp của riêng chúng tôi. Mặc dù nó có vẻ khắc phục được sự cố, nhưng nó không thực sự khắc phục được nguyên nhân cốt lõi của vấn đề. Ví dụ: bạn sẽ có thông lượng ghi cao hơn, nhưng không hoàn toàn ở mức mà trò chơi cần. Tất nhiên, nếu trò chơi của bạn có hàng trăm người chơi, điều này là đủ. Tuy nhiên, nếu bạn muốn xây dựng một trò chơi yêu cầu thông lượng cao hơn, thì sẽ có những ràng buộc rất nghiêm ngặt do cách thức I/O được thực hiện trong bản dựng hiện tại.
Về mặt đọc, bạn không thực sự đạt được hiệu suất. Bạn vẫn cần phải dựa vào người lập chỉ mục. Bạn không thực sự có khả năng mở rộng theo chiều ngang. Nếu bạn cố gắng bắt đầu một bản tổng hợp mới để mở rộng quy mô trò chơi của mình theo chiều ngang, thì bạn sẽ phá hủy hệ sinh thái hợp đồng thông minh hiện tại của mình. Thị trường do người chơi triển khai sẽ không hoạt động với các chuỗi khác mà bạn khởi chạy để mở rộng trò chơi của mình theo chiều ngang. Điều này đặt ra rất nhiều câu hỏi.
Cuối cùng, tỷ lệ đánh dấu cao và khối mỗi giây vẫn là một thách thức nhỏ, mặc dù chúng tôi có thể cố gắng hết sức có thể, chúng tôi có thể nhận được hai khối mỗi giây, có thể là ba, nhưng đây thực sự là những gì mà các chuỗi khối này có thể đạt được. xa nhất, bởi vì có rất nhiều thứ như sắp xếp lại phụ thuộc nhiều vào chu kỳ tính toán.
Để trả lời câu hỏi này, chúng ta hãy nhìn lại đầu những năm 2000 và cuối những năm 1990, khi các trò chơi trực tuyến như MMO mới xuất hiện. Họ có một khái niệm gọi là sharding. Đây không phải là một khái niệm mới; nó đã tồn tại trong quá khứ. Từ "sharding" mà chúng tôi sử dụng trong kiến trúc cơ sở dữ liệu thực sự xuất phát từ một tham chiếu đến Ultima Online. Họ là những người đầu tiên sử dụng từ "shard" để giải thích các máy chủ khác nhau của họ.
Vậy, sharding trong trò chơi hoạt động như thế nào? Nó không phải là một giải pháp phù hợp với một kích cỡ. Đó là một công cụ trong hộp công cụ và cách bạn điều chỉnh nó cho phù hợp với trò chơi của mình sẽ khác nhau tùy theo từng trường hợp. Ví dụ: cấu trúc sharding đầu tiên là cái mà tôi muốn gọi là sharding dựa trên vị trí. Một mô hình tinh thần tốt là tưởng tượng một hệ tọa độ Descartes được chia thành bốn góc phần tư, mỗi góc có phần trò chơi riêng. Mỗi khi bạn muốn đi ngang qua một phân đoạn, bạn sẽ gửi một thông tin liên lạc đến một phân đoạn khác nói rằng "này, tôi muốn chuyển đến đó" và bạn được dịch chuyển đến phân đoạn của mình, để lại những người chơi trước bạn. Bằng cách này, bạn phân phối khối lượng công việc của máy chủ trên nhiều phiên bản vật lý, thay vì buộc một máy chủ thực hiện tất cả công việc tính toán cho toàn bộ thế giới trò chơi. Cấu hình thứ hai bây giờ phổ biến hơn. Nó được gọi là bảo vệ đa vũ trụ, trong đó bạn có nhiều phiên bản trò chơi phản chiếu lẫn nhau. Bạn có thể chọn bất kỳ phân đoạn nào bạn muốn truy cập và nó được cân bằng tải theo mặc định để mỗi máy chủ không bị quá tải.
Bây giờ, câu hỏi chính là, làm thế nào để bạn đưa khái niệm này vào tổng hợp? Đó là lý do tại sao chúng tôi tạo ra World Engine. World Engine là cơ sở hạ tầng hàng đầu của chúng tôi, về cơ bản là một công cụ phân loại phân mảnh cố định được thiết kế để khởi động. Thiết kế của chúng tôi khác biệt và phù hợp hơn với nhu cầu của chúng tôi so với nhiều thiết kế máy phân loại mảnh vỡ mà chúng tôi đã thấy trong một vài cuộc thảo luận trước đây. Hướng tối ưu hóa của chúng tôi là: A, thông lượng, B, chúng tôi muốn đảm bảo rằng không có khóa nào chặn thời gian chạy để đảm bảo rằng tốc độ đánh dấu và thời gian chặn hiệu quả nhất có thể, do đó, theo mặc định, nó được đồng bộ hóa theo cách chúng tôi thiết kế bộ sắp xếp là sắp xếp một phần, thay vì bắt buộc đặt hàng toàn bộ (mỗi giao dịch cần phải xảy ra sau giao dịch khác).
Các thành phần chính ở đây là chúng ta có hai điều chính. Chúng tôi có sharding dựa trên EVM, giống như một chuỗi EVM thuần túy, trên đó người chơi có thể triển khai hợp đồng thông minh, kết hợp với trò chơi, tạo thị trường có thuế, v.v. Nó giống như một chuỗi bình thường, phải không? Đại loại là một khối mỗi giây hay gì đó, vừa đủ để bạn làm tất cả các thiết bị và thị trường điển hình của mình.
Thành phần bí mật ở đây là chúng tôi cũng sử dụng một phân đoạn trò chơi, về cơ bản là một chuỗi khối nhỏ được thiết kế như một máy chủ trò chơi hiệu suất cao. Chúng tôi có giao diện tự triển khai để bạn có thể tùy chỉnh phân đoạn này theo ý thích của mình. Bạn có thể xây dựng các phân đoạn của riêng mình và đưa chúng vào phân đoạn cơ sở. Bạn chỉ cần triển khai một bộ giao diện tiêu chuẩn, giống như Cosmos mà bạn quen thuộc, Cosmos có giao diện ABC. Về cơ bản, bạn có thể kết hợp điều này lại với nhau thành một thông số kỹ thuật tương tự, đưa các phân đoạn của riêng bạn vào ngăn xếp World Engine.
Chìa khóa ở đây là chúng tôi có tỷ lệ đánh dấu cao mà chúng tôi hiện không thể đạt được với cấu trúc bảo vệ hiện tại. Đây là nơi tôi muốn giới thiệu Đức Hồng Y. Cardinal là triển khai sharding trò chơi đầu tiên của World Engine. Nó sử dụng Entity-Component-System (ECS) với kiến trúc hướng dữ liệu. Điều này cho phép chúng tôi song song hóa trò chơi và tăng thông lượng tính toán trò chơi. Nó có tốc độ đánh dấu có thể định cấu hình lên tới 20 đánh dấu mỗi giây. Đối với những người dùng blockchain ở đây, đó là 20 khối mỗi giây.
Chúng tôi cũng có thể định vị địa lý cho nó để giảm độ trễ. Ví dụ: bạn có thể có một máy phân loại ở Hoa Kỳ và sau đó người châu Á phải đợi 300 mili giây để giao dịch đến máy phân loại. Đây là một vấn đề lớn trong trò chơi vì 300 mili giây là một khoảng thời gian dài. Nếu bạn cố gắng chơi một trò chơi FPS với độ trễ 200ms, về cơ bản, bạn đã chết.
Một điểm mấu chốt khác cũng quan trọng đối với chúng tôi là tự lập chỉ mục. Chúng tôi không còn cần người lập chỉ mục bên ngoài. Chúng tôi không cần những khung này để lưu trữ trạng thái trò chơi. Điều này cũng cho phép chúng tôi xây dựng nhiều trò chơi thời gian thực hơn mà không gặp vấn đề về độ trễ do trình lập chỉ mục vẫn đang cố gắng bắt kịp các khối sắp xếp.
Chúng tôi cũng có một hệ thống plugin cho phép mọi người song song xác thực ZK, v.v. Phần tốt nhất, ít nhất là đối với tôi, là bạn có thể viết mã của mình bằng Go. Không còn cần thiết phải sử dụng Solidity để làm cho trò chơi của bạn hoạt động. Nếu bạn đã từng cố gắng xây dựng một trò chơi blockchain với Solidity, thì đó là một cơn ác mộng.
Tuy nhiên, điểm mấu chốt trong quá trình xây dựng phân đoạn của chúng tôi là bạn có thể xây dựng bất cứ thứ gì dưới dạng phân đoạn. Về cơ bản, chúng giống như một không gian thiết kế vô hạn, giống như một mảnh vỡ.
Giả sử bạn không thích viết mã trò chơi của mình trong Go, thì bạn có thể chọn những cách khác. Tuy nhiên, chúng tôi đang làm việc trên một phân đoạn trò chơi Solidity cho phép bạn triển khai các trò chơi trong Solidity, theo cách cung cấp khả năng viết mã trong khi vẫn giữ được nhiều lợi ích của Cardinal. Bạn cũng có thể tạo phân đoạn đúc NFT với cấu trúc sắp xếp và mempool độc đáo, giải quyết vấn đề Hàng xóm ồn ào tương tự như đúc cơ bản. Bạn thậm chí có thể tạo phân đoạn nhận dạng trò chơi và sử dụng NFT để đại diện cho danh tính trò chơi của mình, nhờ đó bạn có thể dễ dàng thực hiện các giao dịch nhận dạng trò chơi thông qua NFT thay vì chia sẻ khóa riêng tư.
Đây là một kiến trúc cấp cao và hôm nay tôi sẽ không đi sâu vào chi tiết quá nhiều do hạn chế về thời gian. Điều quan trọng là chúng tôi cho phép các hợp đồng thông minh EVM được kết hợp với các phân đoạn trò chơi bằng cách sử dụng chọn và vượt qua tùy chỉnh. Chúng tôi đã tạo một trình bao bọc xung quanh Geth để cho phép giao tiếp giữa chúng, điều này mở ra nhiều không gian thiết kế theo cả hai hướng. Chúng tôi được đồng bộ hóa theo mặc định và có thể tương tác liền mạch và kết hợp giữa các phân đoạn mà không cần khóa.
Trình sắp xếp được chia sẻ của chúng tôi khác ở chỗ nó không sử dụng cấu trúc trình tự được chia sẻ mà ưu tiên các gói nguyên tử được sắp xếp toàn cầu, yêu cầu cơ chế khóa và gây ra các vấn đề như chặn luồng chính, dẫn đến tỷ lệ đánh dấu và thời gian chặn không ổn định và kết quả là độ trễ trong tro choi. Nó cũng áp đặt các giới hạn về thời gian chặn trên mỗi phân đoạn và yêu cầu các cấu trúc và kinh tế tiền điện tử khác nhau để ngăn chặn việc từ chối dịch vụ. Có một vấn đề lớn khác mà tôi chưa từng thấy được đề cập trong nhiều cấu trúc bộ sắp xếp VCR: nếu bạn có các phân đoạn khác nhau phụ thuộc vào nhau và bế tắc, bạn sẽ giải quyết nó như thế nào? Với thiết kế không đồng bộ thì đây không phải là vấn đề, vì ai muốn làm gì thì làm, rồi mặc kệ.
Trên thực tế, các chùm nguyên tử và sự cuộn lại giữa các mảnh thường không cần thiết. Đối với trường hợp sử dụng của chúng tôi, chúng tôi không cần bất cứ thứ gì yêu cầu chùm nguyên tử, chúng tôi cũng không nghĩ rằng đó là thứ chúng tôi nên thiết kế Roll-Up của mình xung quanh độ tinh khiết của trường hợp sử dụng. Điều này cũng mang lại nhiều tính năng thú vị khác. Ví dụ: mỗi phân đoạn trò chơi có thể có một lớp DA riêng cho chuỗi cơ sở. Ví dụ: bạn có thể sử dụng phân đoạn cơ sở để đẩy dữ liệu lên Ethereum và phân đoạn trò chơi có thể đẩy dữ liệu lên Celestia (tương tự như ủy ban tính khả dụng của dữ liệu). Bạn cũng có thể giảm các yêu cầu về phần cứng để chạy một nút đầy đủ, bởi vì bạn có thể chạy nút đầy đủ Geth phân đoạn cơ sở một cách riêng biệt mà không cần chạy nút phân đoạn trò chơi, điều này giúp bạn tích hợp với những thứ như Alchemy dễ dàng hơn.
Tóm lại, tôi muốn thành thật ở đây rằng rất nhiều người mong đợi các công trình của họ giải quyết được tất cả các vấn đề của họ, nhưng chúng tôi thì không. Chúng tôi nghĩ rằng cấu trúc của chúng tôi phù hợp với chúng tôi, nhưng nó có thể không phù hợp với trường hợp sử dụng của bạn. Sẽ không thực tế nếu cho rằng các cấu trúc của chúng tôi sẽ phù hợp với tất cả mọi người. Đối với chúng tôi, nó phù hợp với nhu cầu của chúng tôi, cung cấp thông lượng cao, khả năng mở rộng theo chiều ngang, tính linh hoạt và tỷ lệ đánh dấu cao, nhưng nó không phải là thuốc chữa ung thư. Nếu bạn cần một giao thức DeFi yêu cầu khả năng kết hợp đồng bộ, thì cấu trúc này có thể không dành cho bạn.
Nói chung, tôi thực sự tin vào khái niệm kiến trúc chuỗi khối lấy con người làm trung tâm. Bằng cách thiết kế xung quanh vai trò người dùng và trường hợp sử dụng cụ thể, bạn có thể cân bằng tốt hơn thay vì cố gắng giải quyết vấn đề của mọi người. Thời đại phục hưng đã đến và mọi người đều có thể thiết kế Roll-Up của riêng mình để đáp ứng nhu cầu cụ thể của họ, thay vì dựa vào một giải pháp chung. Tôi nghĩ chúng ta nên đón nhận Vụ nổ kỷ Cambri. Đừng xây dựng các cuộn lên như lớp một với một kích cỡ phù hợp với tất cả vì nó hoàn toàn không được thiết kế để giải quyết cùng một vấn đề. Cá nhân tôi rất mong được thấy nhiều người khám phá thêm không gian thiết kế Cuộn lên cho các trường hợp sử dụng. Ví dụ: một Roll-Up được thiết kế đặc biệt để trao đổi tài sản sẽ trông như thế nào? Nó sẽ được dựa trên ý định? Roll-Up được thiết kế đặc biệt cho các CLOB trên chuỗi (Sổ lệnh giới hạn trung tâm) sẽ trông như thế nào? Đây, tôi giao mic cho MJ. Cảm ơn về lời mời của bạn.
Phiên bản tiếng Anh:
Xem bản gốc
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Tại sao Argus sử dụng sharding để xây dựng cơ sở hạ tầng trò chơi toàn chuỗi?
原标题: Tôi đã học cách ngừng lo lắng và chia sẻ tình yêu như thế nào
Liên kêt video:
Diễn giả: Scott Sunarto (@smsunarto) trong Ngày Nghiên cứu
Biên tập và hoàn thiện bài viết: Justin Zhao (@hiCaptainZ)
Xin chào, tôi là Scott (@smsunarto), người sáng lập August Labs (@ArgusLabs_). Hôm nay, tôi sẽ nói về một chủ đề mà chúng ta đã không đề cập đến trong một thời gian. Với việc tổng hợp trở thành xu hướng chủ đạo của thời đại, chúng tôi không thảo luận nhiều về việc bảo vệ quá trình thực thi mà chúng tôi thảo luận về việc bảo vệ dữ liệu. Vì vậy, hãy xem lại chủ đề hơi bị bỏ quên này - phân đoạn thực thi.
Đây sẽ là một cuộc trò chuyện dễ dàng. Tôi biết bạn đã nghe các khái niệm phức tạp cả ngày, vì vậy tôi sẽ cố gắng làm cho cuộc thảo luận này thực tế nhất có thể. Tôi đã chuẩn bị một thiết kế slide phù hợp cho bài thuyết trình này.
Đối với những người không biết tôi, điều buồn cười là, tôi được biết đến trên Twitter với tư cách là một cô gái anime. Tôi cũng đã trượt lễ tốt nghiệp đại học chỉ để đến đây, khiến cha mẹ tôi vô cùng thất vọng. Hiện tại, tôi là người sáng lập Argus Labs. Chúng tôi coi mình là một công ty trò chơi, không phải là một công ty cơ sở hạ tầng hoặc tiền điện tử. Một trong những mối quan tâm lớn nhất của tôi là mọi người chơi trò chơi tiền điện tử đều muốn xây dựng các công cụ, nhưng không ai muốn tạo nội dung hoặc ứng dụng. Chúng tôi cần nhiều ứng dụng hơn mà người dùng thực sự có thể sử dụng.
Trước đây, tôi đã đồng sáng tạo Dark Forest (@darkforest_eth) cùng với những người bạn thông minh của mình là Brian Gu (@gubsheep) và Alan Luo (@alanluo_0). Brian hiện đang chạy 0xPARC (@0xPARC) và anh ấy thông minh hơn tôi rất nhiều.
Cuộc thảo luận hôm nay sẽ tập trung vào việc thực hiện phân đoạn, nhưng trong bối cảnh hầu hết mọi người không quen thảo luận về việc thực hiện phân đoạn. Chúng tôi thường thảo luận về phân đoạn thực thi trong bối cảnh Lớp 1, chẳng hạn như phân đoạn Ethereum hoặc phân đoạn Gần. Nhưng hôm nay, tôi muốn thay đổi bối cảnh một chút. Hãy nghĩ về việc shending sẽ trông như thế nào trong môi trường cuộn lên.
Câu hỏi cơ bản ở đây là tại sao một công ty trò chơi lại xây dựng danh sách tổng hợp của riêng mình và chúng ta có thể học được gì từ World of Warcraft để thiết kế danh sách tổng hợp. Ngoài ra, chúng ta sẽ khám phá cách không gian thiết kế cho cuộn lên vượt xa thực tế hiện tại.
Để trả lời những câu hỏi này, chúng ta hãy quay trở lại năm 2020, khi ý tưởng về Khu rừng tối lần đầu tiên được hình thành. Chúng tôi tự hỏi, điều gì sẽ xảy ra nếu chúng tôi tạo ra một trò chơi trong đó mọi hành động trong trò chơi là một giao dịch trực tuyến? Tiền đề lúc đó thật lố bịch, và nó vẫn còn đối với nhiều người ngày nay. Nhưng đó là một giả thuyết thú vị, vì vậy chúng tôi đã xây dựng nó, và Dark Forest ra đời.
Dark Forest là một trò chơi MMORTS khám phá không gian toàn chuỗi hoàn toàn dựa trên Ethereum, được cung cấp bởi ZK-Snarks. Trở lại năm 2020, ZK không phổ biến như ngày nay vì hầu như không có bất kỳ tài liệu nào. Tài liệu hiện có duy nhất cho Circcom là Google Docs của Jordi Baylina (@jbaylina). Bất chấp những thách thức, chúng tôi đã học được rất nhiều điều trong suốt chặng đường và Dark Forest là hiện thân của những bài học đó.
Dark Forest là một thử nghiệm lớn hơn chúng ta tưởng. Chúng tôi có hơn 10.000 người chơi, hàng nghìn tỷ gas đã tiêu tốn, sự hỗn loạn trong trò chơi, mọi người đâm sau lưng trên dây chuyền. Điều hấp dẫn nhất về Dark Forest và trò chơi trực tuyến là bản chất nền tảng. Bằng cách có một trò chơi toàn chuỗi, bạn mở ra cánh cửa cho một không gian thiết kế cho các hành vi mới nổi, cho phép mọi người xây dựng các hợp đồng thông minh tương tác với trò chơi, cũng như các ứng dụng khách và chế độ trò chơi thay thế, chẳng hạn như Dark Forest Arena và công cụ khai thác GPU.
Tuy nhiên, với sức mạnh lớn đi kèm với trách nhiệm lớn. Khi chúng tôi ra mắt Dark Forest trên xDai, hiện được gọi là Gnosis Chain, cuối cùng chúng tôi đã lấp đầy toàn bộ không gian khối của chuỗi. Điều này làm cho chuỗi về cơ bản không thể sử dụng được cho bất kỳ thứ gì khác, bao gồm DeFi, NFT hoặc bất kỳ thứ xDAI nào khác.
Giờ thì sao? Chúng ta đã đi đến ngõ cụt chưa? Các trò chơi toàn chuỗi sẽ không bao giờ trở thành hiện thực? Hay chúng ta sẽ quay lại làm những trò chơi chỉ có những hình ảnh JPEG nhỏ được lưu trữ trên chuỗi và thuyết phục mọi người rằng tiền sinh sôi nảy nở? Câu trả lời là, chúng tôi để phần mềm làm mọi việc. Nhiều người trong chúng ta có quan điểm rất cứng nhắc về blockchain và roll-up, như thể không có nhiều chỗ để cải thiện. Nhưng tôi không đồng ý. Chúng ta có thể thử nghiệm và tìm ra những khả năng mới.
Chúng tôi đã tự hỏi mình một câu hỏi: nếu chúng tôi thiết kế một chuỗi khối từ đầu cho trò chơi và chỉ trò chơi, thì nó sẽ trông như thế nào? Chúng tôi cần thông lượng cao, vì vậy chúng tôi cần mở rộng quy mô đọc và ghi. Hầu hết các chuỗi khối được thiết kế để ghi nhiều. Số giao dịch mỗi giây (TPS) là một số liệu mà mọi người khoe khoang, nhưng trên thực tế, số lần đọc cũng quan trọng không kém. Làm thế nào để bạn biết vị trí của người chơi nếu bạn không thể đọc từ nút chuỗi khối? Đây thực sự là nút cổ chai đầu tiên mà chúng tôi tìm thấy trong quá trình xây dựng chuỗi khối.
Dark Forest gặp sự cố khi các nút đầy đủ được sử dụng nhiều và I/O bùng nổ vì chúng tôi cần đọc dữ liệu từ trạng thái trên chuỗi. Điều này dẫn đến chi phí máy chủ lên tới hàng nghìn đô la, được nhóm xDAI hào phóng chi trả cho chúng tôi. Tuy nhiên, điều này không lý tưởng cho dài hạn. Chúng tôi cần thông lượng cao, không chỉ cho các giao dịch được viết mỗi giây mà còn cho các lần đọc, chẳng hạn như tìm nạp dữ liệu từ chính chuỗi khối.
Chúng tôi cũng cần một chuỗi khối có thể mở rộng theo chiều ngang để tránh vấn đề Hàng xóm ồn ào. Chúng tôi không muốn một trò chơi phổ biến đột nhiên bắt đầu gặp sự cố trên chuỗi khối, dừng mọi hoạt động. Chúng tôi cũng cần tính linh hoạt và khả năng tùy chỉnh để có thể sửa đổi máy trạng thái được thiết kế cho trò chơi. Điều này bao gồm việc có vòng lặp trò chơi, làm cho trò chơi tự thực hiện, v.v.
Cuối cùng nhưng không kém phần quan trọng, đối với những người không quen thuộc với kiến trúc của trò chơi trực tuyến, điều này có thể hơi mơ hồ, chúng tôi cần tỷ lệ đánh dấu cao. Bọ ve là đơn vị thời gian nguyên tử trong thế giới trò chơi. Trong ngữ cảnh của chuỗi khối, chúng ta có các khối dưới dạng đơn vị thời gian nguyên tử. Trong các trò chơi, chúng tôi có bọ ve. Điều này gần như tương tự khi bạn xây dựng một trò chơi toàn chuỗi, trong đó tốc độ tạo khối hoặc đánh dấu của chuỗi khối của bạn bằng với tốc độ đánh dấu của chính trò chơi đó.
Do đó, những gì chúng ta cần là một chuỗi khối có thông lượng cao, khả năng mở rộng theo chiều ngang, tính linh hoạt và tùy biến cũng như tỷ lệ đánh dấu cao. Thiết kế như vậy có thể đáp ứng nhu cầu của chuỗi khối mà chúng tôi đã thiết kế từ đầu cho trò chơi.
Nếu bạn có tỷ lệ đánh dấu cao hơn hoặc nhiều khối hơn mỗi giây, trò chơi sẽ phản hồi nhanh hơn. Ngược lại, nếu tỷ lệ đánh dấu của bạn thấp, trò chơi sẽ cảm thấy chậm chạp. Một điều quan trọng cần nhớ là nếu các khối bị trì hoãn, bạn sẽ gặp phải tình trạng trễ đáng kể trong trò chơi. Đây là một kinh nghiệm tồi tệ. Nếu bạn đã từng đối phó với những người chơi tức giận hét vào mặt máy tính vì thua một trò chơi, thì đó thực sự là một tình huống tồi tệ.
Hiện tại, các bản tổng hợp của chúng tôi có một khối mỗi giây, tương đương với một lần đánh dấu. Nếu chúng tôi muốn có những trò chơi thú vị hơn, chúng tôi cần tỷ lệ đánh dấu cao hơn. Ví dụ: Minecraft, một trò chơi nghệ thuật pixel đơn giản, có 26 tích tắc mỗi giây. Chúng tôi vẫn còn một chặng đường dài để xây dựng một trò chơi phản ứng nhanh như Minecraft.
Một giải pháp khả thi là triển khai bản tổng hợp của riêng chúng tôi. Mặc dù nó có vẻ khắc phục được sự cố, nhưng nó không thực sự khắc phục được nguyên nhân cốt lõi của vấn đề. Ví dụ: bạn sẽ có thông lượng ghi cao hơn, nhưng không hoàn toàn ở mức mà trò chơi cần. Tất nhiên, nếu trò chơi của bạn có hàng trăm người chơi, điều này là đủ. Tuy nhiên, nếu bạn muốn xây dựng một trò chơi yêu cầu thông lượng cao hơn, thì sẽ có những ràng buộc rất nghiêm ngặt do cách thức I/O được thực hiện trong bản dựng hiện tại.
Về mặt đọc, bạn không thực sự đạt được hiệu suất. Bạn vẫn cần phải dựa vào người lập chỉ mục. Bạn không thực sự có khả năng mở rộng theo chiều ngang. Nếu bạn cố gắng bắt đầu một bản tổng hợp mới để mở rộng quy mô trò chơi của mình theo chiều ngang, thì bạn sẽ phá hủy hệ sinh thái hợp đồng thông minh hiện tại của mình. Thị trường do người chơi triển khai sẽ không hoạt động với các chuỗi khác mà bạn khởi chạy để mở rộng trò chơi của mình theo chiều ngang. Điều này đặt ra rất nhiều câu hỏi.
Cuối cùng, tỷ lệ đánh dấu cao và khối mỗi giây vẫn là một thách thức nhỏ, mặc dù chúng tôi có thể cố gắng hết sức có thể, chúng tôi có thể nhận được hai khối mỗi giây, có thể là ba, nhưng đây thực sự là những gì mà các chuỗi khối này có thể đạt được. xa nhất, bởi vì có rất nhiều thứ như sắp xếp lại phụ thuộc nhiều vào chu kỳ tính toán.
Để trả lời câu hỏi này, chúng ta hãy nhìn lại đầu những năm 2000 và cuối những năm 1990, khi các trò chơi trực tuyến như MMO mới xuất hiện. Họ có một khái niệm gọi là sharding. Đây không phải là một khái niệm mới; nó đã tồn tại trong quá khứ. Từ "sharding" mà chúng tôi sử dụng trong kiến trúc cơ sở dữ liệu thực sự xuất phát từ một tham chiếu đến Ultima Online. Họ là những người đầu tiên sử dụng từ "shard" để giải thích các máy chủ khác nhau của họ.
Vậy, sharding trong trò chơi hoạt động như thế nào? Nó không phải là một giải pháp phù hợp với một kích cỡ. Đó là một công cụ trong hộp công cụ và cách bạn điều chỉnh nó cho phù hợp với trò chơi của mình sẽ khác nhau tùy theo từng trường hợp. Ví dụ: cấu trúc sharding đầu tiên là cái mà tôi muốn gọi là sharding dựa trên vị trí. Một mô hình tinh thần tốt là tưởng tượng một hệ tọa độ Descartes được chia thành bốn góc phần tư, mỗi góc có phần trò chơi riêng. Mỗi khi bạn muốn đi ngang qua một phân đoạn, bạn sẽ gửi một thông tin liên lạc đến một phân đoạn khác nói rằng "này, tôi muốn chuyển đến đó" và bạn được dịch chuyển đến phân đoạn của mình, để lại những người chơi trước bạn. Bằng cách này, bạn phân phối khối lượng công việc của máy chủ trên nhiều phiên bản vật lý, thay vì buộc một máy chủ thực hiện tất cả công việc tính toán cho toàn bộ thế giới trò chơi. Cấu hình thứ hai bây giờ phổ biến hơn. Nó được gọi là bảo vệ đa vũ trụ, trong đó bạn có nhiều phiên bản trò chơi phản chiếu lẫn nhau. Bạn có thể chọn bất kỳ phân đoạn nào bạn muốn truy cập và nó được cân bằng tải theo mặc định để mỗi máy chủ không bị quá tải.
Bây giờ, câu hỏi chính là, làm thế nào để bạn đưa khái niệm này vào tổng hợp? Đó là lý do tại sao chúng tôi tạo ra World Engine. World Engine là cơ sở hạ tầng hàng đầu của chúng tôi, về cơ bản là một công cụ phân loại phân mảnh cố định được thiết kế để khởi động. Thiết kế của chúng tôi khác biệt và phù hợp hơn với nhu cầu của chúng tôi so với nhiều thiết kế máy phân loại mảnh vỡ mà chúng tôi đã thấy trong một vài cuộc thảo luận trước đây. Hướng tối ưu hóa của chúng tôi là: A, thông lượng, B, chúng tôi muốn đảm bảo rằng không có khóa nào chặn thời gian chạy để đảm bảo rằng tốc độ đánh dấu và thời gian chặn hiệu quả nhất có thể, do đó, theo mặc định, nó được đồng bộ hóa theo cách chúng tôi thiết kế bộ sắp xếp là sắp xếp một phần, thay vì bắt buộc đặt hàng toàn bộ (mỗi giao dịch cần phải xảy ra sau giao dịch khác).
Các thành phần chính ở đây là chúng ta có hai điều chính. Chúng tôi có sharding dựa trên EVM, giống như một chuỗi EVM thuần túy, trên đó người chơi có thể triển khai hợp đồng thông minh, kết hợp với trò chơi, tạo thị trường có thuế, v.v. Nó giống như một chuỗi bình thường, phải không? Đại loại là một khối mỗi giây hay gì đó, vừa đủ để bạn làm tất cả các thiết bị và thị trường điển hình của mình.
Thành phần bí mật ở đây là chúng tôi cũng sử dụng một phân đoạn trò chơi, về cơ bản là một chuỗi khối nhỏ được thiết kế như một máy chủ trò chơi hiệu suất cao. Chúng tôi có giao diện tự triển khai để bạn có thể tùy chỉnh phân đoạn này theo ý thích của mình. Bạn có thể xây dựng các phân đoạn của riêng mình và đưa chúng vào phân đoạn cơ sở. Bạn chỉ cần triển khai một bộ giao diện tiêu chuẩn, giống như Cosmos mà bạn quen thuộc, Cosmos có giao diện ABC. Về cơ bản, bạn có thể kết hợp điều này lại với nhau thành một thông số kỹ thuật tương tự, đưa các phân đoạn của riêng bạn vào ngăn xếp World Engine.
Chìa khóa ở đây là chúng tôi có tỷ lệ đánh dấu cao mà chúng tôi hiện không thể đạt được với cấu trúc bảo vệ hiện tại. Đây là nơi tôi muốn giới thiệu Đức Hồng Y. Cardinal là triển khai sharding trò chơi đầu tiên của World Engine. Nó sử dụng Entity-Component-System (ECS) với kiến trúc hướng dữ liệu. Điều này cho phép chúng tôi song song hóa trò chơi và tăng thông lượng tính toán trò chơi. Nó có tốc độ đánh dấu có thể định cấu hình lên tới 20 đánh dấu mỗi giây. Đối với những người dùng blockchain ở đây, đó là 20 khối mỗi giây.
Chúng tôi cũng có thể định vị địa lý cho nó để giảm độ trễ. Ví dụ: bạn có thể có một máy phân loại ở Hoa Kỳ và sau đó người châu Á phải đợi 300 mili giây để giao dịch đến máy phân loại. Đây là một vấn đề lớn trong trò chơi vì 300 mili giây là một khoảng thời gian dài. Nếu bạn cố gắng chơi một trò chơi FPS với độ trễ 200ms, về cơ bản, bạn đã chết.
Một điểm mấu chốt khác cũng quan trọng đối với chúng tôi là tự lập chỉ mục. Chúng tôi không còn cần người lập chỉ mục bên ngoài. Chúng tôi không cần những khung này để lưu trữ trạng thái trò chơi. Điều này cũng cho phép chúng tôi xây dựng nhiều trò chơi thời gian thực hơn mà không gặp vấn đề về độ trễ do trình lập chỉ mục vẫn đang cố gắng bắt kịp các khối sắp xếp.
Chúng tôi cũng có một hệ thống plugin cho phép mọi người song song xác thực ZK, v.v. Phần tốt nhất, ít nhất là đối với tôi, là bạn có thể viết mã của mình bằng Go. Không còn cần thiết phải sử dụng Solidity để làm cho trò chơi của bạn hoạt động. Nếu bạn đã từng cố gắng xây dựng một trò chơi blockchain với Solidity, thì đó là một cơn ác mộng.
Tuy nhiên, điểm mấu chốt trong quá trình xây dựng phân đoạn của chúng tôi là bạn có thể xây dựng bất cứ thứ gì dưới dạng phân đoạn. Về cơ bản, chúng giống như một không gian thiết kế vô hạn, giống như một mảnh vỡ.
Giả sử bạn không thích viết mã trò chơi của mình trong Go, thì bạn có thể chọn những cách khác. Tuy nhiên, chúng tôi đang làm việc trên một phân đoạn trò chơi Solidity cho phép bạn triển khai các trò chơi trong Solidity, theo cách cung cấp khả năng viết mã trong khi vẫn giữ được nhiều lợi ích của Cardinal. Bạn cũng có thể tạo phân đoạn đúc NFT với cấu trúc sắp xếp và mempool độc đáo, giải quyết vấn đề Hàng xóm ồn ào tương tự như đúc cơ bản. Bạn thậm chí có thể tạo phân đoạn nhận dạng trò chơi và sử dụng NFT để đại diện cho danh tính trò chơi của mình, nhờ đó bạn có thể dễ dàng thực hiện các giao dịch nhận dạng trò chơi thông qua NFT thay vì chia sẻ khóa riêng tư.
Đây là một kiến trúc cấp cao và hôm nay tôi sẽ không đi sâu vào chi tiết quá nhiều do hạn chế về thời gian. Điều quan trọng là chúng tôi cho phép các hợp đồng thông minh EVM được kết hợp với các phân đoạn trò chơi bằng cách sử dụng chọn và vượt qua tùy chỉnh. Chúng tôi đã tạo một trình bao bọc xung quanh Geth để cho phép giao tiếp giữa chúng, điều này mở ra nhiều không gian thiết kế theo cả hai hướng. Chúng tôi được đồng bộ hóa theo mặc định và có thể tương tác liền mạch và kết hợp giữa các phân đoạn mà không cần khóa.
Trình sắp xếp được chia sẻ của chúng tôi khác ở chỗ nó không sử dụng cấu trúc trình tự được chia sẻ mà ưu tiên các gói nguyên tử được sắp xếp toàn cầu, yêu cầu cơ chế khóa và gây ra các vấn đề như chặn luồng chính, dẫn đến tỷ lệ đánh dấu và thời gian chặn không ổn định và kết quả là độ trễ trong tro choi. Nó cũng áp đặt các giới hạn về thời gian chặn trên mỗi phân đoạn và yêu cầu các cấu trúc và kinh tế tiền điện tử khác nhau để ngăn chặn việc từ chối dịch vụ. Có một vấn đề lớn khác mà tôi chưa từng thấy được đề cập trong nhiều cấu trúc bộ sắp xếp VCR: nếu bạn có các phân đoạn khác nhau phụ thuộc vào nhau và bế tắc, bạn sẽ giải quyết nó như thế nào? Với thiết kế không đồng bộ thì đây không phải là vấn đề, vì ai muốn làm gì thì làm, rồi mặc kệ.
Trên thực tế, các chùm nguyên tử và sự cuộn lại giữa các mảnh thường không cần thiết. Đối với trường hợp sử dụng của chúng tôi, chúng tôi không cần bất cứ thứ gì yêu cầu chùm nguyên tử, chúng tôi cũng không nghĩ rằng đó là thứ chúng tôi nên thiết kế Roll-Up của mình xung quanh độ tinh khiết của trường hợp sử dụng. Điều này cũng mang lại nhiều tính năng thú vị khác. Ví dụ: mỗi phân đoạn trò chơi có thể có một lớp DA riêng cho chuỗi cơ sở. Ví dụ: bạn có thể sử dụng phân đoạn cơ sở để đẩy dữ liệu lên Ethereum và phân đoạn trò chơi có thể đẩy dữ liệu lên Celestia (tương tự như ủy ban tính khả dụng của dữ liệu). Bạn cũng có thể giảm các yêu cầu về phần cứng để chạy một nút đầy đủ, bởi vì bạn có thể chạy nút đầy đủ Geth phân đoạn cơ sở một cách riêng biệt mà không cần chạy nút phân đoạn trò chơi, điều này giúp bạn tích hợp với những thứ như Alchemy dễ dàng hơn.
Tóm lại, tôi muốn thành thật ở đây rằng rất nhiều người mong đợi các công trình của họ giải quyết được tất cả các vấn đề của họ, nhưng chúng tôi thì không. Chúng tôi nghĩ rằng cấu trúc của chúng tôi phù hợp với chúng tôi, nhưng nó có thể không phù hợp với trường hợp sử dụng của bạn. Sẽ không thực tế nếu cho rằng các cấu trúc của chúng tôi sẽ phù hợp với tất cả mọi người. Đối với chúng tôi, nó phù hợp với nhu cầu của chúng tôi, cung cấp thông lượng cao, khả năng mở rộng theo chiều ngang, tính linh hoạt và tỷ lệ đánh dấu cao, nhưng nó không phải là thuốc chữa ung thư. Nếu bạn cần một giao thức DeFi yêu cầu khả năng kết hợp đồng bộ, thì cấu trúc này có thể không dành cho bạn.
Nói chung, tôi thực sự tin vào khái niệm kiến trúc chuỗi khối lấy con người làm trung tâm. Bằng cách thiết kế xung quanh vai trò người dùng và trường hợp sử dụng cụ thể, bạn có thể cân bằng tốt hơn thay vì cố gắng giải quyết vấn đề của mọi người. Thời đại phục hưng đã đến và mọi người đều có thể thiết kế Roll-Up của riêng mình để đáp ứng nhu cầu cụ thể của họ, thay vì dựa vào một giải pháp chung. Tôi nghĩ chúng ta nên đón nhận Vụ nổ kỷ Cambri. Đừng xây dựng các cuộn lên như lớp một với một kích cỡ phù hợp với tất cả vì nó hoàn toàn không được thiết kế để giải quyết cùng một vấn đề. Cá nhân tôi rất mong được thấy nhiều người khám phá thêm không gian thiết kế Cuộn lên cho các trường hợp sử dụng. Ví dụ: một Roll-Up được thiết kế đặc biệt để trao đổi tài sản sẽ trông như thế nào? Nó sẽ được dựa trên ý định? Roll-Up được thiết kế đặc biệt cho các CLOB trên chuỗi (Sổ lệnh giới hạn trung tâm) sẽ trông như thế nào? Đây, tôi giao mic cho MJ. Cảm ơn về lời mời của bạn.
Phiên bản tiếng Anh: