Tác giả: PolkaWorld

Gavin Wood, đồng sáng lập Ethereum, người sáng lập Polkadot và là người thúc đẩy tầm nhìn của Web3.

Trước khi bắt đầu chính thức, hãy chia sẻ một số câu nói nổi bật của Gavin trong phần này!

Thành tựu lớn nhất của Ethereum cho đến nay là gì? - Có lẽ là CryptoKitties, tôi không biết, thực sự không chắc chắn. Tôi nghe nói Ethereum đã tạo ra nhiều triệu phú nhất trong lịch sử.

Ethereum có phải là một dự án thành công không? - Nếu theo tiêu chí thành công của tôi thì sao? Rõ ràng không phải tất cả các tiêu chí đều phù hợp, thậm chí có thể chỉ một phần nhỏ là phù hợp. Tất nhiên, về mặt tài chính thì nó là thành công.

Với sự ra đời của JAM, hướng đi của Polkadot đã thay đổi. Nó có thể được coi là một chuỗi lưu trữ Rollup có thiết kế bản địa, trong khi công nghệ mà chúng tôi phát triển vượt trội hơn nhiều so với Optimistic Rollup và ZK Rollup trên Ethereum.

Thành tựu lớn nhất của Polkadot cho đến nay là gì? - Đã đạt được một blockchain phân mảnh an toàn.

Vấn đề lớn nhất mà Polkadot đang đối mặt hôm nay là gì? - Chính là phân mảnh.

Làm thế nào để giải quyết những vấn đề này? - JAM

Tiếp tục đọc để xem tất cả nội dung!

Thành tựu lớn nhất của Ethereum cho đến nay là gì?

Kevin: Vậy bạn nói rằng bạn đã đồng sáng lập Ethereum vào năm 2014? Tại sao bạn lại tham gia với tư cách là đồng sáng lập và giám đốc công nghệ?

Gavin: Tôi cảm thấy đây là một cơ hội hiếm có, ngay lập tức nhận ra rằng tôi nên nắm bắt nó và đầu tư toàn bộ sức lực vào đó. Có thể không phải là đầu tư cả đời, nhưng ít nhất trong một khoảng thời gian dài sắp tới, tôi sẽ dồn hết tâm sức vào đó. Đây là một dự án đổi mới xuất hiện vào thời điểm thích hợp, với một nhóm người tài năng và tập trung, và một thị trường nhỏ nhưng tràn đầy hứng thú và sẵn sàng thử nghiệm. Thành thật mà nói, tôi rất tò mò về dự án này, tôi cảm thấy nó có tiềm năng rất lớn để phát triển xa hơn và ít nhất có thể đóng góp cho những nguyên tắc tự do khai sáng mà tôi hiểu.

Kevin: Điều đó là gì?

Gavin: Cơ bản là quan điểm lạc quan về xã hội và phát triển, tư tưởng này có thể đã phát triển ở phương Tây khoảng bốn đến năm trăm năm trước.

Kevin: Thành tựu lớn nhất của Ethereum cho đến nay là gì?

Gavin: Có lẽ là CryptoKitties, tôi không biết, thực sự không chắc chắn. Tôi nghe nói Ethereum đã tạo ra nhiều triệu phú nhất trong lịch sử. Có thể là vì số lượng người tham gia trong đợt huy động vốn cộng đồng rất lớn, và giá sau đó tăng cao đủ để tạo ra điều đó. Vì vậy, có thể đây là đóng góp lớn nhất của nó. Nhưng thành thật mà nói, rất khó để nói xem nó thực sự đã đạt được bao nhiêu điều hữu ích. Chắc chắn không đạt được kỳ vọng của tôi cách đây 10 năm.

Kevin: Vậy nếu tôi hỏi bạn, bạn có nghĩ rằng Ethereum là một dự án thành công không? Câu trả lời của bạn có phải là không?

Gavin: Câu trả lời của tôi là, tôi cá nhân nghĩ nó có thành công không? Nếu theo tiêu chí thành công của tôi thì sao? Rõ ràng không phải tất cả các tiêu chí đều phù hợp, thậm chí có thể chỉ một phần nhỏ là phù hợp. Tất nhiên, về mặt tài chính thì nó là thành công. Tôi nghĩ có thể một hoặc hai đồng sáng lập Ethereum đã kỳ vọng rằng nó sẽ hoạt động tốt hơn.

Kevin: Có những tiêu chí nào khiến bạn nghĩ rằng nó là thành công?

Gavin: Tính hữu dụng (Utility)

Kevin: Làm thế nào để đo lường tính hữu dụng?

Gavin: Cách đo lường tính hữu dụng là xem có bao nhiêu điều mà mọi người hiện nay có thể làm mà trước đây không thể làm.

Kevin: Đây có phải là vấn đề của toàn bộ ngành công nghiệp tiền mã hóa, chứ không chỉ là vấn đề của Ethereum không?

Gavin: Đúng vậy. Đây thực sự là vấn đề mà toàn bộ ngành công nghiệp tiền mã hóa đang đối mặt. Vào năm 2014 và 2015, chúng tôi đã đưa ra nhiều ý tưởng, cố gắng mở khóa một số lĩnh vực kinh tế mà trước đây không thể tiếp cận bằng cách “không cần tin tưởng”. Một trong những ví dụ mà tôi đặc biệt thích là chuỗi cung ứng. Ví dụ, khi bạn đến siêu thị, tất cả các sản phẩm đều có một mã QR, bạn có thể quét mã QR để tìm hiểu tất cả các thành phần của sản phẩm đó: khi nào, ở đâu và số lượng,... Tôi hy vọng rằng khi mua một chiếc áo phông, tôi có thể biết bông của nó đến từ đâu.

Hiện tại, việc này rất khó thực hiện trong mô hình tập trung, và chi phí cũng rất cao. Nhưng nếu áp dụng cách tiếp cận phi tập trung, tôi nghĩ là khả thi. Tuy nhiên, ứng dụng như vậy vẫn chưa được triển khai thực sự. Mặc dù hiện tại có một số dự án tiền mã hóa liên quan đến chuỗi cung ứng, nhưng chúng rất nhỏ và chỉ giới hạn trong các lĩnh vực ngách của thị trường cụ thể. Nó chưa thực sự thực hiện được những lời hứa trong hướng đi này.

Hơn nữa, đây không chỉ là vấn đề của chuỗi cung ứng, tôi nghĩ rằng trí tưởng tượng của ngành công nghiệp tiền mã hóa rất phong phú, nhưng rất khó để biến những tưởng tượng này thành hành động thực tế và ứng dụng thị trường thực sự, điều này thực sự đáng tiếc. Tôi nghĩ nguyên nhân chính không phải là vấn đề công nghệ, mặc dù công nghệ thực sự còn tụt hậu so với những gì chúng tôi tưởng tượng, đặc biệt là công nghệ nền tảng cần được cải tiến rất nhiều. Đó cũng là lý do tại sao tôi hiện đang làm JAM, cố gắng cải thiện công nghệ nền tảng để hỗ trợ những ý tưởng mà tôi cho là có giá trị và giúp ngành công nghiệp tiền mã hóa phát huy vai trò lớn hơn.

Nhưng chỉ cải thiện công nghệ là không đủ. Bạn cũng cần khiến mọi người hiểu giá trị của nó. Và điều này rất khó, một phần là vì bạn đang chiến đấu với nền kinh tế chú ý.

Tại sao lại rời bỏ Ethereum?

Kevin: Tại sao bạn lại rời bỏ Ethereum vào năm 2016?

Gavin: Thực ra là vào cuối năm 2015. Lúc đó chúng tôi quyết định rằng Ethereum cần làm nhiều việc để được phổ biến rộng rãi hơn. Chúng tôi đang tìm kiếm đầu tư bên ngoài, và một trong những cách rõ ràng nhất là thành lập một công ty khởi nghiệp liên quan đến Ethereum và tìm kiếm sự hỗ trợ tài chính từ bên ngoài. Đây ban đầu là quyết định chung của Vitalik và Jeff (các nhà phát triển và kỹ sư cốt lõi).

Sau đó, Jeff không thích cuộc sống khởi nghiệp. Thực tế, anh ấy đã nhanh chóng rời Ethereum để theo đuổi sự nghiệp trò chơi điện tử của mình. Kết quả là, cuối cùng chỉ còn lại Vitalik. Vitalik cho rằng anh cần tiếp tục ở lại Ethereum Foundation và đảm nhận vai trò học thuật hơn, đồng thời là cố vấn cho công ty con Ethcore mà chúng tôi đã thành lập lúc đó.

Chúng tôi đã huy động được một số vốn, đưa khoảng một nửa đội ngũ kỹ thuật của Ethereum Foundation sang Ethcore, và phát triển một client Ethereum. Tôi rời Ethereum Foundation vào cuối năm 2015 thực ra là để thành lập công ty con này, với mục đích tăng cường một thực thể được hỗ trợ tài chính tư nhân trong hệ sinh thái Ethereum.

Tuy nhiên, tôi thực sự hoàn toàn rời khỏi hệ sinh thái Ethereum vào cuối năm 2017, khi tôi thành lập Polkadot.

Polkadot đang phát triển công nghệ Rollup

Kevin: Nếu phải giải thích Polkadot là gì cho mẹ bạn, bạn sẽ nói thế nào?

Gavin: Ờ... Polkadot đã xảy ra một số thay đổi trong những năm qua. Tầm nhìn ban đầu là tích hợp các kiến trúc blockchain khác nhau lại với nhau để chúng có thể tương thích với nhau và chia sẻ cùng một khung bảo mật. Với khung bảo mật chia sẻ như vậy, có thể cải thiện hiệu quả kinh tế một cách đáng kể. Ví dụ, nếu được thiết kế tốt, có thể bảo vệ cùng lúc 100 chuỗi với cùng một chi phí, thay vì mỗi chuỗi như các thiết kế khác (như Cosmos) cần phải tự bảo vệ.

Trong suốt nhiều năm, Polkadot đã cố gắng phân biệt mình với Cosmos ở khía cạnh này. Bởi vì trong mô hình Cosmos, mỗi chuỗi cần tự gánh chịu tính bảo mật. Trong khi Polkadot giải quyết vấn đề này thông qua bảo mật chia sẻ. Nhưng thật đáng tiếc, hai bên thực sự đang giải quyết những vấn đề rất khác nhau. Nhìn lại, tôi có thể nghiêng về việc mô tả Polkadot như một “hệ thống phân mảnh”, hơn là một “hệ thống đa chuỗi”. Nhìn lại, cách diễn đạt này rất quan trọng trong việc giải thích và truyền đạt ý tưởng cốt lõi của Polkadot. Đặc biệt là trong việc giao tiếp hoặc quảng bá Polkadot với người khác, sự khác biệt này giúp mô tả rõ ràng hơn các đặc điểm kỹ thuật của nó và sự khác biệt với các dự án khác (như Cosmos).

Bây giờ, với sự ra đời của JAM, hướng đi này đã xảy ra một số thay đổi. Công nghệ mà chúng tôi phát triển cho Polkadot có thể được coi là một công nghệ Rollup, trong khi Polkadot bản thân nó có thể được coi là một chuỗi lưu trữ Rollup được thiết kế đặc biệt. Việc phát triển và thiết kế công nghệ này không đơn giản, vì vậy không có gì ngạc nhiên khi chúng tôi thấy hai công nghệ cạnh tranh khác có hiệu quả kém xa so với công nghệ mà chúng tôi phát triển cho Polkadot. Cụ thể là Optimistic Rollups và ZK Rollups, cả hai công nghệ này đều đã được sử dụng trên Ethereum. Vì vậy, chúng tôi có thể mô tả Polkadot như một chuỗi lưu trữ Rollup bản địa - tất nhiên, cách nói này có thể không phù hợp để giải thích cho mẹ, nhưng đối với những người có hiểu biết về lĩnh vực tiền mã hóa thì là thích hợp.

Thông qua JAM, tức là mục tiêu phát triển tiếp theo của Polkadot, chúng tôi cố gắng chuyển Polkadot từ một mô hình đa chuỗi thành một mô hình tài nguyên tính toán tổng quát hơn. Trong mô hình đa chuỗi, các chuỗi khác nhau của Polkadot (trong hệ thống Polkadot được gọi là các chuỗi song song) chia sẻ cùng một khung bảo mật, có thể tương tác với nhau. Trong mô hình mới, mục tiêu của chúng tôi là mở rộng hơn nữa phạm vi áp dụng của Polkadot, giống như cách Ethereum đã mở rộng các chức năng cơ bản của Bitcoin thành một nguồn tài nguyên tính toán tổng quát. Chúng tôi hy vọng loại bỏ các giới hạn thiết kế chủ quan quá mức, để Polkadot hỗ trợ nhiều trường hợp sử dụng hơn.

Vậy tương lai của Polkadot là gì? Về cơ bản, nó sẽ trở thành một máy tính chia sẻ lớn, luôn hoạt động theo cách mà bạn mong đợi. Trên máy tính chia sẻ này, bạn có thể tải lên các chương trình để chạy, những chương trình này có thể là các dịch vụ giải quyết các vấn đề cụ thể. Bởi vì đây là một máy tính chia sẻ, những dịch vụ này có thể phối hợp và hợp tác với nhau.

Điều quan trọng là, đây là một máy tính chia sẻ lớn duy nhất. Điều mà chúng tôi không muốn làm là chia nó thành các phần khác nhau, mà những phần đó không thể thực sự tương tác với nhau.

Thành tựu lớn nhất của Polkadot cho đến nay chính là vấn đề lớn nhất của nó

Kevin: Tôi nghĩ có lẽ bạn đang chỉ đến một thực tế mà chúng ta đều biết, điều này thực sự đã gây ra nhiều nhầm lẫn trong hệ sinh thái Ethereum ngày nay. Vậy, thành tựu lớn nhất của Polkadot cho đến nay là gì?

Gavin: Đã đạt được một blockchain phân mảnh an toàn.

Kevin: Vấn đề lớn nhất mà Polkadot đang đối mặt hôm nay là gì?

Gavin: Chính là phân mảnh.

Kevin: Điều này cụ thể có nghĩa là gì?

Gavin: Phân mảnh từ lâu đã được coi là “Chén thánh” của sự mở rộng blockchain, khái niệm của nó đến từ thiết kế cơ sở dữ liệu. Trong cơ sở dữ liệu, bạn có thể chia một cơ sở dữ liệu (về bản chất là một tập hợp các bản ghi) thành nhiều phân mảnh. Mỗi phân mảnh hoạt động độc lập, chỉ có thể tương tác giữa các phân mảnh trong một số trường hợp rất rõ ràng, ví dụ như một bản ghi có thể di chuyển từ một phân mảnh sang một phân mảnh khác.

Một ví dụ vật lý đơn giản có thể giúp hiểu điều này. Hãy tưởng tượng một văn phòng vào những năm 60, chẳng hạn như một phòng khám bác sĩ, nơi có hồ sơ y tế của bệnh nhân. Những hồ sơ này thường được lưu trữ trong những ngăn kéo cũ. Nếu hồ sơ chỉ có 20 người, có thể một ngăn kéo đã đủ chứa, và rất dễ dàng sắp xếp theo thứ tự chữ cái. Nhưng nếu hồ sơ vượt quá sức chứa của một ngăn kéo, chẳng hạn như có nhiều người hơn, bạn sẽ cần phải phân tán hồ sơ vào nhiều ngăn kéo. Nếu số lượng ngăn kéo tiếp tục tăng lên, chẳng hạn như cần bốn hoặc năm ngăn kéo, bạn sẽ cần nhiều tủ tài liệu.

Mỗi ngăn kéo trong tủ tài liệu có thể được coi là một phân mảnh. Chúng hoạt động độc lập với nhau: bạn có thể mở một ngăn kéo mà không cần mở các ngăn kéo khác, hoặc bạn có thể tìm kiếm trong một ngăn kéo mà không cần xem tất cả các ngăn kéo. Điều này trái ngược với việc chỉ có một ngăn kéo dài đặc biệt (chẳng hạn như ngăn kéo dài 10 mét). Nếu chỉ có một ngăn kéo dài, thì rõ ràng là không thực tế, vì bạn sẽ cần một căn phòng dài 10 mét để chứa nó. Và khi bạn muốn tìm một người có tên bắt đầu bằng chữ “W”, bạn có thể phải kéo toàn bộ ngăn kéo ra và đi dọc theo ngăn kéo đến vị trí “W”, rõ ràng là không hiệu quả.

Vì vậy, từ góc độ này, thiết kế phân mảnh là hợp lý. Tuy nhiên, điều này cũng mang lại vấn đề. Chẳng hạn, nếu một ngăn kéo đầy thì phải làm sao? Bạn có thể cần phải điều chỉnh lại sự phân phối của các bản ghi, chẳng hạn như thay đổi các bản ghi từ A đến E thành A đến D, sau đó chuyển các bản ghi bắt đầu bằng E sang ngăn kéo bên dưới. Nhưng điều này có thể dẫn đến ngăn kéo tiếp theo cũng không đủ chỗ, vì vậy bạn lại cần điều chỉnh, và mỗi lần điều chỉnh lại phải thay đổi nhãn bên ngoài ngăn kéo. Toàn bộ quá trình này sẽ trở nên phức tạp và rắc rối.

Vì vậy, phân mảnh cũng gây ra một loạt vấn đề riêng của nó.

Điều cốt lõi là, những “ngăn kéo” (phân mảnh) này hoạt động độc lập, dù trong thiết kế blockchain phân mảnh hay thiết kế cơ sở dữ liệu. Về bản chất, dữ liệu bị chia sẻ sẽ luôn giữ tình trạng phân mảnh, trừ khi bạn thực hiện một thao tác rất đặc biệt, điều này thường rất tốn thời gian, tốn kém và tiêu tốn tài nguyên, để chuyển bản ghi hoặc dữ liệu từ một ngăn kéo (phân mảnh) sang một ngăn kéo (phân mảnh) khác. Điều này có nghĩa là việc tổ chức lại các bản ghi trong một ngăn kéo có thể dễ dàng, nhưng việc tổ chức lại các bản ghi giữa các ngăn kéo thì rất khó khăn. Đây chính là vấn đề của phân mảnh. Đối với dữ liệu, vấn đề này có thể không nghiêm trọng, đó cũng là lý do tại sao phân mảnh được áp dụng rộng rãi trong thiết kế cơ sở dữ liệu. Nhưng đối với dịch vụ, chẳng hạn như các hợp đồng thông minh cần tương tác và thay đổi thường xuyên, cách tiếp cận này không lý tưởng. Nếu hợp đồng thông minh được coi là các đối tượng được đặt trong ngăn kéo, và bạn muốn cho một hợp đồng thông minh trong một ngăn kéo tương tác với một hợp đồng thông minh trong ngăn kéo khác, bạn sẽ cần phải mở cả hai ngăn kéo cùng một lúc. Điều này có nghĩa là, bạn cần kéo cả hai ngăn kéo ra, kết nối chúng với nhau, thực hiện tất cả các thao tác tương tác cần thiết của các hợp đồng thông minh, rồi lại tách chúng ra, đặt lại vào ngăn kéo của chúng. Quá trình này phức tạp và không hiệu quả, rất không phù hợp với các kịch bản ứng dụng cần tương tác thường xuyên.

Nếu bạn chỉ thao tác giữa hai ngăn kéo, đã đủ khó, nhưng nếu bạn muốn nhiều ngăn kéo tương tác cùng một lúc, thì sẽ trở nên rất phức tạp và khó khăn. Một vấn đề của việc này là, bạn đã ngăn chặn sự tương tác tự do giữa các ngăn kéo, điều này có nghĩa là các hợp đồng thông minh khác trong ngăn kéo chỉ có thể tuân theo mô hình tương tác đơn lẻ này. Toàn bộ hệ thống sẽ nhanh chóng trở nên phức tạp, khó khăn và không hiệu quả.

Một cách khác là để các ngăn kéo giao tiếp với nhau bằng cách gửi tin nhắn. Một ngăn kéo (phân mảnh) có thể phát hành một tin nhắn, sau đó tin nhắn này sẽ được chuyển đến một ngăn kéo khác. Đó chính là những gì Polkadot đang làm với XCM (tín hiệu truyền thông giữa các đồng thuận). Mặc dù cách này có thể sử dụng, nhưng vấn đề là, nó không thể đạt được sự tương tác chặt chẽ, hiệu quả và linh hoạt, không mượt mà bằng khi mọi thứ hoạt động trong cùng một không gian hoặc “sân chơi”.

Lấy một ví dụ, giả sử một trường học có bốn sân chơi khác nhau, điều này tương ứng với bốn blockchain khác nhau. Nếu bạn chơi trò “trốn tìm” trong một sân chơi, thì không vấn đề gì, trò chơi có thể diễn ra suôn sẻ. Nhưng nếu bạn muốn chơi “trốn tìm” giữa hai sân chơi, điều đó sẽ trở nên rất khó khăn. Bạn cần gửi một tin nhắn đến sân chơi khác, chẳng hạn như “bây giờ tôi là người tìm, nếu bạn vào khu vực này, tôi sẽ bắt được bạn.” Và người chơi ở sân chơi khác cần biết, nhưng lại không thể hiểu hoàn toàn, toàn bộ trò chơi sẽ nhanh chóng trở nên hỗn loạn.

Vì vậy, trò chơi trốn tìm là một trò chơi chỉ có thể chơi trong cùng một sân chơi. Đây chính là vấn đề giữa các phân mảnh, sự tương tác giữa các phân mảnh giống như cố gắng chơi trò chơi giữa các sân chơi, rất khó thực hiện một cách hiệu quả.

Nếu một số giải pháp phải hoạt động theo cách rất bất đồng bộ, thì việc làm cho chúng hoạt động bình thường sẽ trở nên rất khó khăn. Giống như chỉ có thể chơi qua tin nhắn vậy. Nếu là một trò chơi như cờ vua, có thể không quá khó; nhưng nếu là một trò chơi như trốn tìm, thì gần như là không thể.

Tình huống này cũng tương tự trong hợp đồng thông minh. Một số hợp đồng thông minh hoạt động trong mô hình này không quá khó khăn, có thể chỉ chậm hơn một chút so với tốc độ bình thường, nhưng không vấn đề gì. Trong khi một số kịch bản ứng dụng, chẳng hạn như xác minh danh tính (KYC), lại tương đối đơn giản. Chẳng hạn, bạn có thể có một chuỗi chuyên trách xác minh danh tính, và một chuỗi khác xử lý chuyển khoản. Chuỗi chuyển khoản có thể cần xác nhận địa chỉ đích có đã qua xác minh KYC và AML hay chưa, trước khi thực hiện chuyển khoản. Nó có thể gửi một tin nhắn hỏi “địa chỉ này có được xác minh KYC và AML không?” Chuỗi xác minh danh tính trả lời “có”, sau đó chuỗi chuyển khoản thực hiện chuyển khoản. Toàn bộ quá trình có thể mất thêm vài giây, nhưng không vấn đề gì.

Tuy nhiên, còn một số trường hợp sử dụng khác, chẳng hạn như sàn giao dịch phi tập trung (DEX), thì phức tạp hơn nhiều. Chẳng hạn, bạn cần hỏi giá hiện tại, sau đó quyết định xem có nên giao dịch hay không. Lúc này bạn có thể cần gửi một tin nhắn đến một chuỗi khác, chuỗi khác trả lời rằng “giá hiện tại là này, giao dịch có thể thực hiện như vậy.” Sau đó tin nhắn quay trở lại chuỗi gốc, chuỗi gốc xác nhận “tôi chấp nhận giá này, hãy thực hiện giao dịch.” Nhưng khi giao dịch sắp được thực hiện, chuỗi khác có thể lại nói “giá đã thay đổi, bây giờ là giá này.” Tin nhắn sẽ liên tục quay đi quay lại, rất nhanh chóng toàn bộ quá trình sẽ trở nên rất không hiệu quả, thậm chí không thể hoàn thành một cách hiệu quả.

Vì vậy, trong những trường hợp như vậy, giao dịch phải hoàn thành gần như đồng thời, nếu không sẽ không thể thực hiện. Hiện tượng này giống như việc chơi trò chơi ở sân chơi. Một số trò chơi, chẳng hạn như trốn tìm, chỉ có thể hoàn thành trong cùng một không gian, tương tác bất đồng bộ sẽ khiến trò chơi không thể thực hiện.

Giải pháp là JAM

Kevin: Có giải pháp khả thi nào không?

Gavin: Ờ, JAM là đề xuất của tôi, tức là Join Accumulate Machine (Máy kết nối tích lũy).

Kevin: JAM là gì?

Gavin: JAM là một cách linh hoạt, nó có thể tập hợp người chơi từ các “sân chơi” khác nhau lại với nhau, tạo ra một sân chơi tạm thời để họ có thể chơi trò trốn tìm. Dưới đây là một ví dụ ngẫu hứng (có thể hơi điên rồ, xin lỗi). Tiếp tục với ví dụ về trò trốn tìm: giả sử có bốn sân chơi cố định, trong thiết kế của JAM, không còn sân chơi cố định như vậy.

Sân chơi không còn cố định, và người chơi cũng không còn bị ràng buộc trong một sân chơi nào đó, và chi phí di chuyển giữa các sân chơi cũng sẽ không cao như vậy. Thay vào đó, chúng tôi có một khu vực chơi rộng lớn, trong đó các sân chơi có thể nhanh chóng hình thành và biến mất. Trong trường hợp này, chúng tôi sẽ tập trung vào những người chơi trong trò chơi, tạm thời tập hợp những người chơi gần nhau, có khả năng “bắt” nhau lại với nhau, tạo ra một sân chơi tạm thời, nơi họ có thể tiếp tục chơi trốn tìm.

Khi một phần trong số những người chơi này chạy ra khỏi sân chơi tạm thời này, chúng tôi sẽ điều chỉnh lại vị trí của sân chơi, xác định lại phạm vi sân chơi mới dựa trên những người chơi vẫn còn gần nhau. Nếu có những người chơi cách xa nhau, chúng tôi biết rằng họ sẽ không “bắt” nhau trong thời gian ngắn, vì vậy họ không cần tham gia vào sân chơi này. Họ tạm thời ở trong trạng thái “ngoài trò chơi”, cho đến khi họ lại gần những người chơi khác và cần tham gia trò chơi, mới được đưa vào sân chơi mới.

Nếu chúng tôi thực hiện hệ thống này theo cách linh hoạt hơn, có thể tưởng tượng một hệ thống vừa có khả năng mở rộng vừa hỗ trợ kết hợp đồng bộ. Cốt lõi của nó là, sẽ không phân chia vĩnh viễn cái gọi là “trạng thái” (state). Nói cách khác, người chơi sẽ không bị ràng buộc cố định trong một sân chơi cụ thể nào đó, mà sẽ được nhóm lại một cách linh hoạt theo nhu cầu theo thời gian thực. Hệ thống sẽ phân chia người chơi thành các nhóm khác nhau theo nhu cầu thực tế và thúc đẩy trò chơi dựa trên những nhóm này.

Trong bối cảnh hợp đồng thông minh, việc hiện thực hóa khái niệm này tương tự như việc đặt tất cả các hợp đồng thông minh vào một “lò nấu” lớn chia sẻ, nhưng lò này không phải là nơi tất cả các hợp đồng tương tác liên tục, mà là có thể phân khu động. Ví dụ, hệ thống có thể rút ra 10, 50 hoặc 2 hợp đồng thông minh từ lò này, kết hợp chúng lại để chúng tương tác và chạy đồng bộ, sau đó lại tách chúng ra. Sau đó đánh giá lại, chọn một tập hợp hợp đồng thông minh khác, lại kết hợp và chạy, rồi lại tách ra.

Cách này cho phép chúng tôi xử lý nhiều nhóm hợp đồng thông minh song song cùng một lúc, thay vì chỉ cho phép một nhóm hợp đồng thông minh thực hiện kết hợp và chạy đồng bộ. Thông qua phương pháp xử lý song song này, chúng tôi có thể tăng cường đáng kể khả năng xử lý tương tác của hệ thống, hỗ trợ số lượng tương tác gấp hàng trăm lần so với cách truyền thống, từ đó đạt được khả năng mở rộng thực sự.