Argus: Bắt đầu từ Dark Forest, tại sao chúng ta lấy lại được sharding?

Tiêu đề gốc: "Tại sao Argus sử dụng sharding để xây dựng cơ sở hạ tầng trò chơi toàn chuỗi"

Nguồn gốc: Scott Sunarto

Bản tổng hợp gốc: CaptainZ

Bài viết này được viết bởi Scott Sunarto, người sáng lập Bài thuyết trình về Ngày Nghiên cứu của Phòng thí nghiệm Argus. Scott tốt nghiệp trường Berkeley và là thành viên của eGirl, trước đây anh đã tham gia vào việc tạo ra trò chơi dark forest trên chuỗi nổi tiếng. Trong bài phát biểu này, Scott không chỉ chia sẻ những kinh nghiệm và khó khăn trước đây gặp phải trong khu rừng tối mà còn giải thích lý do Argus chọn phân mảnh L2+ để xây dựng game engine. Sau đây là toàn văn bài phát biểu được biên soạn bởi người dùng Twitter CaptainZ (@hiCaptainZ):

Xin chào mọi người, tôi là Scott (@smsunarto), người sáng lập Augus Labs (@ArgusLabs_). Hôm nay, tôi sẽ thảo luận về một chủ đề mà đã lâu rồi chúng ta không đề cập tới. Khi tính năng cuộn lên trở thành xu hướng phổ biến của thời đại, chúng tôi không thảo luận về việc phân mảnh thực thi thường xuyên như phân mảnh dữ liệu. Vì vậy, hãy cùng xem lại chủ đề có phần bị bỏ qua 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 tất cả các bạn đã nghe những 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 trở nên 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.

Dành cho những ai không Tôi không biết tôi. Thật buồn cười, tôi được biết đến như một cô gái anime trên Twitter. Tôi cũng bỏ lỡ lễ tốt nghiệp đại học để đến đây, khiến bố mẹ tôi không hài lò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 hay tiền điện tử. Một trong những điều khiến tôi khó chịu nhất là mọi người trong 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 và những người bạn thông minh của mình là Brian Gu (@gubsheep) và Alan Luo (@alanluo_0) đồng sáng tạo Rừng tối (@darkforest_eth). Brian hiện chạy 0xPARC (@0xPARC) và 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 sharding, nhưng trong Đây là trong bối cảnh mà hầu hết mọi người đều không quen với việc thảo luận về phân đoạn thực thi. Chúng ta thường thảo luận về phân mảnh thực thi trong bối cảnh Lớp 1, chẳng hạn như phân mảnh Ethereum hoặc phân mảnh Gần. Nhưng hôm nay tôi muốn thay đổi bối cảnh. Hãy suy nghĩ về việc phân mảnh 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 các bản cuộn của riêng mình và những gì chúng ta có thể học được từ World of Warcraft để thiết kế các bản cuộn. Ngoài ra, chúng ta sẽ khám phá cách không gian thiết kế dành cho dạng cuộn mở rộng 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, Đó là 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 đều là giao dịch trực tuyến? Tiền đề lúc đó thật vô lý, và nó vẫn còn tồn tại đối với nhiều người ngày nay. Nhưng đó là một giả thuyết thú vị nên chúng tôi đã xây dựng nó và Dark Forest đã ra đời.

Dark Forest là một không gian toàn chuỗi dựa hoàn toàn trên Ethereum Khám phá các trò chơi MMORTS được cung cấp bởi ZK-Snarks. Trở lại năm 2020, ZK chưa phổ biến như ngày nay vì hầu như không có tài liệu nào. Tài liệu duy nhất có sẵn cho Circom 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 đó.

Khu rừng tối Đó là một thử nghiệm lớn hơn chúng tôi tưởng tượng. Chúng tôi có hơn 10.000 người chơi, tiêu tốn hàng nghìn tỷ gas, rất nhiều sự hỗn loạn trong trò chơi và có nhiều người đâm sau lưng chuỗi. Điều hấp dẫn nhất về Dark Forest và trò chơi trực tuyến là tính 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 đến 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ế như Dark Forest Arena và công cụ khai thác GPU.

Tuy nhiên, quyền lực 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, 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ứ gì khác có xDAI.

Vậy bây giờ thì sao? Chúng ta đã đến ngõ cụt chưa? 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 trò chơi chỉ với một ít ảnh JPEG trên chuỗi và thuyết phục mọi người rằng tiền mọc trên cây? Câu trả lời là chúng ta để 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à các hệ thống cuộn, 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 ta tự hỏi mình một câu hỏi: Điều gì sẽ xảy ra nếu chúng ta bắt đầu? Thiết kế một blockchain cho trò chơi và chỉ dành cho trò chơi, 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 blockchain được thiết kế để thực hiện nhiều thao tác ghi. Số giao dịch mỗi giây (TPS) là một số liệu được mọi người chào mời, nhưng trên thực tế, số lần đọc cũng quan trọng không kém. Nếu bạn không thể đọc từ nút blockchain, làm sao bạn biết vị trí của người chơi? Đây thực sự là nút thắt cổ chai đầu tiên mà chúng tôi tìm thấy trong quá trình xây dựng blockchain của mình.

Dark Forest gặp phải một vấn đề, đó là số lượng lớn trong số các nút đầy đủ đang sử dụng vụ nổ I/O 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ủ hàng nghìn đô la, được nhóm xDAI chi trả một cách hào phóng cho chúng tôi. Tuy nhiên, điều này không lý tưởng về lâu dài. Chúng ta cần thông lượng cao, không chỉ cho các giao dịch được ghi mỗi giây mà còn cho các lần đọc, chẳng hạn như lấy dữ liệu từ chính blockchain.

Chúng tôi cũng cần một blockchain có thể mở rộng theo chiều ngang, Để tránh ồn ào Vấn đề hàng xóm. Chúng tôi không muốn một trò chơi phổ biến đột nhiên gặp sự cố trên blockchain, khiến mọi công việc phải dừng lại. 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ó một vòng lặp trò chơi, làm cho nó 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 với kiến trúc trò chơi trực tuyến Đối với một số người, điều này có thể hơi mơ hồ, chúng tôi cần tỷ lệ đánh dấu cao. Ticks là đơn vị thời gian nguyên tử trong thế giới trò chơi. Trong bối cảnh của blockchain, chúng ta có các khối là đơn vị thời gian nguyên tử. Trong trò chơi, chúng ta có bọ ve. Điều này gần như tương tự khi bạn đang xây dựng một trò chơi toàn chuỗi, trong đó số tích tắc trên blockchain của bạn hoặc tốc độ tạo ra các khối bằng với số tích tắc của chính trò chơi.

Vì vậy, cái chúng ta cần là một mức độ cao Thông lượng, blockchain có thể mở rộng theo chiều ngang, linh hoạt và có thể tùy chỉnh với tỷ lệ đánh dấu cao. Chỉ kiểu thiết kế này mới có thể đáp ứng nhu cầu của blockchain 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 đánh dấu mỗi giây Bạn càng có nhiều khối, trò chơi sẽ càng phản hồi nhanh hơn. Ngược lại, nếu tỷ lệ đánh dấu của bạn thấp hơn, trò chơi sẽ có cảm giác chậm chạp hơn. Một điều quan trọng cần nhớ là nếu các đoạn tạo ra độ trễ, bạn sẽ cảm thấy độ trễ rõ rệt trong trò chơi. Đó là một trải nghiệm tồi tệ. Nếu bạn từng gặp phải một người chơi tức giận la mắng máy tính vì họ thua một trò chơi thì đó là một tình huống cực kỳ khủng khiếp.

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 tích tắc. Nếu chúng ta muốn có những trò chơi thú vị hơn, chúng ta cần có 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 trước khi có thể xây dựng một trò chơi có khả năng phản hồi 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ù bề ngoài nó có vẻ giải quyết được vấn đề nhưng thực tế nó không giải quyết được nguyên nhân gốc rễ của vấn đề. Ví dụ: bạn sẽ có thông lượng ghi cao hơn nhưng vẫn chưa đạt đến mức mà trò chơi của bạn cần. Tất nhiên, nếu trò chơi của bạn có một trăm người chơi thì đ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 hạn chế rất nghiêm trọng do cách xây dựng I/O 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 tung ra 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, bạn sẽ phá vỡ hệ sinh thái hợp đồng thông minh hiện có của mình. Các 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 theo chiều ngang. Điều này đặt ra nhiều câu hỏi.

Cuối cùng, tốc độ đánh dấu cao và số khối mỗi giây vẫn là Nó khó hơn một chút, mặc dù chúng tôi có thể đẩy nó mạnh nhất có thể và chúng tôi có thể nhận được hai khối mỗi giây, có thể là ba, nhưng đó thực sự là thứ xa nhất mà các chuỗi khối này có thể đi được bởi vì có rất nhiều thứ như sắp xếp lại những thứ như thế này phụ thuộc rất nhiều vào chu kỳ tính toán.

Để giải quyết câu hỏi này, chúng ta hãy nhìn lại đầu thế kỷ 21 thế kỷ và Đó là vào cuối những năm 1990, khi các trò chơi trực tuyến như MMO mới nổi lê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ó đã có từ trước đây. Từ "sharding" mà chúng tôi sử dụng trong kiến trúc cơ sở dữ liệu thực ra có nguồn gốc từ tham chiếu đến Ultima Online. Lần đầu tiên họ sử dụng từ "sharding" để giải thích các máy chủ khác nhau của mình.

Vậy, sharding hoạt động như thế nào trong trò chơi? ? Nó không phải là một giải pháp phù hợp cho tất 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 tùy thuộc vào tình huống. Ví dụ: cấu trúc sharding đầu tiên là thứ 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à hãy 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 phần tư có ô trò chơi riêng. Mỗi khi bạn muốn di chuyển qua một phân đoạn, bạn sẽ gửi một thông báo đến một phân đoạn khác với nội dung "Này, tôi muốn di chuyển đến đó" và bạn sẽ được dịch chuyển đến phân đoạn của mình, bỏ lại Thân xác của người chơi trước đó. 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ác phép tính cho toàn bộ thế giới trò chơi. Việc xây dựng thứ hai bây giờ phổ biến hơn. Nó được gọi là phân đoạn đ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à phân đoạ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 quan trọng là làm thế nào để đưa khái niệm này vào Nhập 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à về cơ bản là một trình sắp xếp phân đoạn được thiết kế để khởi chạy. So với nhiều thiết kế máy phân loại phân mảnh mà chúng tôi đã thấy trong một số cuộc thảo luận trước đây, 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. 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 tốc độ đánh dấu và thời gian chặn hiệu quả nhất có thể nên mặc định là đồng bộ và 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ì buộc phải sắp xếp tổng số (mỗi giao dịch cần phải xảy ra sau một giao dịch khác).

Thành phần quan trọng ở đây là chúng ta có hai điều chính. Chúng tôi có shending dựa trên EVM, giống như một chuỗi EVM thuần túy mà trên đó người chơi có thể triển khai các hợp đồng thông minh, kết hợp với trò chơi, tạo ra thị trường có thuế, v.v. Nó giống như một sợi dây chuyền bình thường phải không? Giống như một khối hoặc một thứ mỗi giây, vừa đủ để bạn thực hiện tất cả các thiết bị và nội dung tiếp thị thông thường của mình.

Bí quyết ở đây là chúng tôi cũng sử dụng điểm số của trò chơi Slice, về cơ bản là một blockchain 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 triển khai do chính bạn thực hiện để 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 các 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ể hợp nhất thông số này thành một thông số kỹ thuật tương tự và đưa các phân đoạn của riêng bạn vào ngăn xếp World Engine.

Điều quan trọng ở đây là chúng tôi có tỷ lệ đánh dấu cao, Hiện tại chúng tôi không thể đạt được điều này với cấu trúc sharding 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 phân đoạn trò chơi đầu tiên cho World Engine. Nó sử dụng Hệ thống thực thể-thành phần (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 hiệu suất tính toán của trò chơi. Nó có tốc độ đánh dấu có thể định cấu hình lên tới 20 tích tắc mỗi giây. Đối với những người sử dụng blockchain ở đây, đó là 20 khối mỗi giây.

Chúng tôi cũng có thể nhắm mục tiêu theo địa lý để Giảm độ trễ. Ví dụ: bạn có thể có trình sắp xếp thứ tự ở Hoa Kỳ và sau đó mọi người ở Châu Á phải đợi độ trễ 300 mili giây để giao dịch đến được trình sắp xếp thứ tự. Đâ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 game FPS có độ trễ 200 mili giây thì về cơ bản, bạn sẽ chết.

Một điểm quan trọng khác cũng quan trọng đối với chúng tôi Vâng, nó được 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 nữa. Chúng tôi không cần những khung này để lưu trạng thái trò chơi vào bộ nhớ đệm. Đ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ễ vì người 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 minh 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 trong Go. Không còn phải sử dụng Solidity để trò chơi của bạn hoạt động. Nếu bạn đã từng thử xây dựng một trò chơi blockchain bằng Solidity thì đó quả là một cơn ác mộng.

Tuy nhiên, điểm mấu chốt trong cấu trúc sharding của chúng tôi là Bạn có thể xây dựng bất cứ thứ gì như một mảnh vỡ. Về cơ bản, chúng giống như một không gian thiết kế vô hạn về những gì một phân đoạn có thể có.

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 cách khác. Tuy nhiên, chúng tôi đang phát triể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, điều này sẽ giữ lại nhiều lợi thế của Cardinal đồng thời cung cấp khả năng mã hóa. Bạn cũng có thể tạo phân đoạn đúc NFT với nhóm bộ nhớ duy nhất và cấu trúc đặt hàng, 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 thể hiện danh tính trò chơi của bạn dưới dạng NFT, để bạn có thể dễ dàng giao dịch danh tính trò chơi của mình thông qua NFT thay vì chia sẻ khóa riêng tư.

Đây là một kiến trúc nâng cao. Do hạn chế về thời gian, tôi Sẽ không thể đi sâu vào chi tiết quá nhiều. Điều quan trọng là chúng tôi cho phép kết hợp các hợp đồng thông minh EVM với các phân đoạn trò chơi bằng cách sử dụng tùy chọn chọn và vượt qua. Chúng tôi đã tạo một lớp 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. Theo mặc định, chúng tôi đồng bộ và có thể tương tác giữa các phân đoạn một cách liền mạch và tổng hợp mà không cần khóa.

Bộ sắp xếp được chia sẻ của chúng tôi khác biệt vì nó không sử dụng cấu trúc trình tự chung của các gói nguyên tử ưu tiên thứ tự toàn cầu, điều này đòi hỏi cơ chế khóa và dẫn đến các vấn đề như chặn luồng chính, dẫn đến tốc độ đánh dấu và thời gian chặn không ổn định, dẫn đến trò chơi bị lag. Nó cũng đặt ra các giới hạn về thời gian khối trên mỗi phân đoạn và yêu cầu nhiều 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ụ. Ngoài ra còn có một vấn đề lớn mà tôi không thấy được đề cập trong nhiều cấu trúc trình sắp xếp VCR: nếu bạn có các phân đoạn khác nhau phụ thuộc lẫn nhau và tạo ra bế tắc, bạn giải quyết nó như thế nào? Với thiết kế không đồng bộ, đây không phải là vấn đề vì mọi người đều làm những gì họ muốn và sau đó quên mất nó.

Trên thực tế, các chùm nguyên tử xuyên mảnh và cuộn lại 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 kỳ thứ gì yêu cầu chùm nguyên tử và chúng tôi cũng không nghĩ rằng đây là thứ chúng tôi nên thiết kế các Bản cuộn của mình sao cho phù hợp với trường hợp sử dụng. Điều này còn mang lại nhiều tính chất 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 sang Ethereum và phân đoạn trò chơi có thể đẩy dữ liệu tới Celestia (tương tự như ủy ban về tính khả dụng của dữ liệu). Bạn cũng giảm các yêu cầu về phần cứng để chạy một nút đầy đủ vì bạn có thể chạy riêng nút đầy đủ Geth được phân chia cơ sở mà không cần phải chạy nút phân đoạn trò chơi, điều này giúp bạn dễ dàng tích hợp hơn với những thứ như Alchemy.

Tóm lại, tôi muốn thành thật ở đây và nói rằng rất nhiều người muốn cấu trúc của họ giải quyết được mọi vấn đề của họ, nhưng điều đó không xảy ra với chúng tôi. 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. Thật không thực tế khi cho rằng cấu trúc của chúng tôi sẽ áp dụng cho 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 và 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à phương pháp chữa khỏi bệnh 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.

Chung cho đối với tôi, tôi thực sự tin tưởng vào khái niệm kiến trúc blockchain lấy con người làm trung tâm. Bằng cách thiết kế xoay quanh các vai trò và trường hợp sử dụng cụ thể của người dùng, bạn có thể cân nhắc tốt hơn và không cố gắng giải quyết vấn đề của mọi người. Thời kỳ phục hưng đã đến khi mọi người có thể thiết kế Roll-Up của riêng mình phù hợp với nhu cầu cụ thể của mình thay vì dựa vào các giải pháp chung cho tất cả. Tôi nghĩ chúng ta nên đón nhận sự bùng nổ kỷ Cambri. Đừng xây dựng các bản cuộn như lớp một trong những lớp phù hợp cho tất cả vì đơn giản là nó không được thiết kế để giải quyết cùng một vấn đề. Cá nhân tôi mong muốn được thấy nhiều người khám phá nhiều hơn về không gian thiết kế Cuộn lên dành riêng cho các trường hợp sử dụng. Ví dụ: Roll-Up được thiết kế đặc biệt để trao đổi tài sản sẽ trông như thế nào? Nó sẽ dựa trên ý định? Roll-Up được thiết kế đặc biệt cho 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 đưa mic cho MJ. Cảm ơn về lời mời của bạn.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia