Chính xác thì "JAM", hướng nâng cấp trong tương lai của Polkadot là gì?

Để hỗ trợ sự phát triển của JAM và đảm bảo rằng nó được xây dựng trên tinh thần phi tập trung thực sự, Gavin đã cùng tuyên bố thành lập phần thưởng JAM với Web3 Foundation trong bài phát biểu của mình. Tổng cộng 10 triệu DOT sẽ được sử dụng để khích lệ. phát triển các triển khai khác của JAM .

Cùng lúc với bài phát biểu, Gavin cũng đưa ra một tờ báo kỹ thuật màu xám. Nếu bạn muốn tìm hiểu sâu hơn về viễn cảnh mong đợi và chi tiết kỹ thuật của dự án, bạn có thể tìm thấy bài viết trên trang web JAM Graypaper mới: https://graypaper.com/.

Cùng nhau, Gavin và Polkadot đang dẫn đầu việc tạo ra các công nghệ tiên tiến nhằm hiện thực hóa viễn cảnh mong đợi tạo ra một mở mạng và miễn phí. JAM là chương tiếp theo trong câu chuyện Polkadot đang phát triển.

Sau đây là phần giới thiệu mới nhất về JAM từ Polkadot Wiki, được viết bởi Gavin Wood.

Tên đầy đủ của JAM là Máy tích lũy tham gia, đây là một thiết kế mới được lên kế hoạch thay thế Chuỗi chuyển tiếp hiện có. Tên JAM có nguồn gốc từ CoreJAM, viết tắt của Collect Refine Join Accumulate và mô tả mô hình điện toán được thể hiện bởi máy. Nó ban đầu được mô tả trong RFC bởi Gavin Wood. Tuy nhiên, trong Chuỗi thực tế, chỉ Tham gia và Tích lũy được thực hiện, trong khi các quy trình Thu thập và Tinh chỉnh diễn ra ngoài Chuỗi.

Không giống như phương pháp lặp đi lặp lại hiện tại, JAM sẽ được giới thiệu dưới dạng một nâng cấp toàn diện. Một vài lý do để làm điều này bao gồm:

• Nâng cấp hợp nhất có thể hạn chế chính xác các hoạt động sau nâng cấp, điều này khó thực hiện theo phương pháp lặp đi lặp lại.

• Nó làm giảm số lượng nâng cấp nhỏ và những thay đổi lớn thường xảy ra định kì trong nhiều tuần hoặc nhiều tháng.

Mặc dù quá trình chuyển đổi này sẽ đòi hỏi những thay đổi đột phá đáng kể nhưng chúng tôi sẽ nỗ lực giảm tác động của nó xuống mức có thể quản lý được. Tốt hơn là nên hợp nhất nhiều thay đổi đột phá nhỏ hơn thành một quá trình chuyển đổi duy nhất, đưa ra khái niệm blockchain mới và tích hợp nhiều ý tưởng hiện có khác nhau.

JAM sẽ là một Chuỗi dành riêng cho từng miền để xử lý các vấn đề dành riêng cho từng miền. Trong trường hợp này, đó là một bản tổng hợp, mà cộng đồng Ethereum gọi là bản tổng hợp lạc quan. Bản tổng hợp của JAM rất hạn chế về mặt bảo mật. Đây là những gì Polkadot đã làm trong 5 năm qua, nó đã trở thành một Chuỗi tổng hợp dành riêng cho từng miền . Về cơ bản, JAM làm cho nó linh hoạt hơn với ít tùy chọn đặt trước hơn.

Chuỗi JAM lấy đầu ra của một bản tổng hợp và nói chung là các bit tính toán được thực hiện ở nơi khác và tích hợp đầu ra vào trạng thái chia sẻ, tương tự như chức năng của Chuỗi chuyển tiếp Polkadot .

Nhiệm vụ của Chuỗi JAM là cung cấp các thiết bị cần thiết để đảm bảo đầu ra phản ánh chính xác đầu vào sau khi được chuyển đổi.

JAM có một số điểm tương đồng với Chuỗi hợp đồng thông minh:

• Bản thân Chuỗi JAM trực tiếp thực thi mã không được phép.

• Trạng thái của Chuỗi JAM được tổ chức thành các gói khác nhau.

• Ngoài việc đóng gói trạng thái, nó còn bao gồm việc đóng gói mã và số dư.

Việc đóng gói các trạng thái này được gọi là dịch vụ. Do đó, trạng thái của JAM được chia thành các dịch vụ. Việc tạo các dịch vụ mới là không cần cấp phép, tương tự như việc triển khai hợp đồng thông minh trên Chuỗi hợp đồng thông minh. Do đó, việc thêm các dịch vụ mới vào Chuỗi JAM không yêu cầu bất kỳ sự phê duyệt hoặc tuân thủ có thẩm quyền nào với các cơ chế quản trị, không giống như Chuỗi dựa trên Chất nền, yêu cầu phê duyệt quản trị để bổ sung các pallet mới. Các dịch vụ bao gồm mã, số dư và một số thành phần trạng thái nhất định, tương tự như các cấu trúc thường thấy trên Chuỗi hợp đồng thông minh.

Mã cho dịch vụ JAM được chia thành ba điểm nhập khác nhau:

• Tinh chỉnh là hàm thực hiện hầu hết các phép tính không trạng thái. Nó xác định các phép biến đổi để tổng hợp một dịch vụ cụ thể.

• Hàm Tích lũy lấy đầu ra và thu gọn nó thành trạng thái tổng thể của dịch vụ

• OnTransfer xử lý thông tin từ các dịch vụ khác.

Gói công việc là đầu vào cho các dịch vụ. Một gói công việc có thể chứa nhiều hạng mục công việc. Mỗi hạng mục công việc được liên kết với một dịch vụ và nó phản ánh đầu vào thực tế của dịch vụ đó. Đối với các dịch vụ Chuỗi, đây là nơi thực hiện các giao dịch và tất cả đầu vào blockchain.

Thiết bị an toàn của JAM bao gồm xử lý hai giai đoạn, trong đó chức năng Tinh chỉnh chấp nhận các mục công việc làm đầu vào và tạo ra kết quả công việc dưới dạng đầu ra, sau đó nhập chức năng Tích lũy (Tinh chỉnh trước, sau đó Tích lũy). Các hạng mục công việc được tinh chế thành kết quả công việc. Do đó, một gói công việc chứa nhiều hạng mục công việc được tinh chế thành một báo cáo báo cáo công việc. Một gói công việc có thể được chỉ định để sử dụng lõi trong một khoảng thời gian cụ thể (thường là 6 giây).

JAM khác với Chuỗi hợp đồng thông minh ở chỗ hoạt động không cần giao dịch. Không có giao dịch nào trong JAM; tất cả các hành động đều không được phép và ban đầu đều trải qua giai đoạn Tinh chỉnh. Ở giai đoạn này, dịch vụ sẽ tinh chỉnh trước dữ liệu đầu vào và chuyển nó thành báo cáo công việc chứa kết quả công việc. Kết quả của những nỗ lực này sau đó được chuyển giao trên Chuỗi.

Mặc dù không có giao dịch nhưng JAM vẫn chấp nhận thông tin bên ngoài ở một định dạng cụ thể. Có 5 loại thông tin bên ngoài:

1. Bảo đảm

2. Bảo hiểm (Assurances)

3. Phán quyết

4. Tiền ảnh

5. Vé

Ba loại đầu tiên là một phần của khung bảo mật Chuỗi JAM. "Đảm bảo" và "Đảm bảo" liên quan đến việc người xác thực chứng minh chung rằng kết quả công việc phản ánh chính xác kết quả của hạng mục công việc tương ứng sau khi được chuyển đổi bởi chức năng "Tinh chỉnh" của dịch vụ.

Phán quyết xảy ra khi tính toàn vẹn của kết quả công việc bị nghi ngờ, khi lượng lớn người xác nhận chứng thực tính hợp lệ của nó hoặc thiếu tính hợp lệ của nó. Trong trường hợp này, các mục công việc không hợp lệ có thể đã được tích hợp vào trạng thái của dịch vụ và có thể cần phải được khôi phục. Phán quyết phải được đưa ra trong vòng một giờ sau khi gửi báo cáo công việc cho Chuỗi, trong thời gian đó khối tạm thời bị đình chỉ.

Hình ảnh trước là một tính năng được Chuỗi JAM cung cấp cho chức năng Tinh chỉnh. Mặc dù hàm Tinh chỉnh thường không có trạng thái nhưng nó có thể thực hiện một thao tác có trạng thái: tra cứu tiền ảnh băm. Tính năng này là khía cạnh duy nhất của chức năng Tinh chỉnh có tùy chọn mặc định.

Vé vào cơ chế sản xuất khối dưới dạng mục nặc danh. Chúng không phải là yêu cầu trực tiếp cho việc sản xuất khối; thay vào đó, hệ thống vận hành trước hai kỷ nguyên. Cơ chế này là một phần của thuật toán SAFROL, một phiên bản cải tiến của thuật toán SASSAFRAS ban đầu.

Trong JAM, giai đoạn xử lý Tinh chỉnh có thể chấp nhận tối đa 15 MB dữ liệu trong mỗi khoảng thời gian, mỗi khoảng thời gian kéo dài 6 giây. Tuy nhiên, dữ liệu liệu đầu ra tối đa của Refine là 90 kB, đòi hỏi lượng lớn nén dữ liệu lớn do tính chất phân tán của hệ thống sẵn có. Ví dụ: trong bối cảnh Chuỗi , 15 MB dữ liệu đại diện cho Bằng chứng về tính hợp lệ (PoV), trong khi 90 kB dữ liệu tương ứng với biên nhận của ứng viên.

Tinh chỉnh có thể sử dụng tối đa 6 giây PVM Gas, tương đương với toàn bộ thời gian chặn của Chuỗi chuyển tiếp. Thời gian thực hiện kéo dài này, so với giới hạn hai giây hiện tại của PVF, đạt được thông qua đo lường an toàn và các tối ưu hóa khác.

Tinh chỉnh cũng có thể thực hiện tìm kiếm trước hình ảnh. Nếu bạn tin rằng một hàm băm nhất định và tiền ảnh liên quan của nó có sẵn trên Chuỗi JAM thì bạn có thể yêu cầu tiền ảnh bằng cách cung cấp hàm băm. Khả năng này cho phép lưu trữ và truy xuất mã hiệu quả, chẳng hạn như bằng cách lưu trữ mã Chuỗi trên Chuỗi JAM và tham chiếu hàm băm của nó trong gói công việc.

Tinh chỉnh là công cụ xử lý chính, xử lý nhiệm vụ hầu hết là các hoạt động không trạng thái.

Hàm Tích lũy chịu trách nhiệm tích hợp đầu ra do hàm Tinh chỉnh tạo ra vào trạng thái Chuỗi. Tích lũy có thể chấp nhận nhiều đầu ra từ Tinh chỉnh, tất cả đều có nguồn gốc từ cùng một dịch vụ. Tinh chỉnh và Tích lũy đều đóng vai trò là điểm vào từ một khối mã dịch vụ cụ thể.

Thời gian thực thi của Accumulate trên mỗi đầu ra ngắn hơn nhiều so với Refine, thường chỉ tối đa 10 mili giây. Tuy nhiên, thời lượng phụ thuộc vào số lượng hạng mục công việc trong gói công việc. Nếu một gói công việc chứa nhiều mục thì thời gian khả dụng sẽ được chia cho chúng.

Không giống như Tinh chỉnh, Tích lũy có trạng thái và có thể truy cập trạng thái của Chuỗi JAM . Nó có thể đọc bộ nhớ từ bất kỳ dịch vụ nào, ghi vào kho lưu trữ khóa-giá trị, chuyển tiền và bao gồm các bản ghi nhớ khi tiền được chuyển. Ngoài ra, Accumulate có thể tạo các dịch vụ mới, nâng cấp mã của chúng, yêu cầu cung cấp hình ảnh trước, v.v.

Ngoài ra, Refine có thể gọi các phiên bản con của PVM. Điều này cho phép tạo các phiên bản phụ hoặc máy ảo trong đó mã và dữ liệu có thể được triển khai, tùy chỉnh cấu hình bộ nhớ và ngăn xếp cũng như thực hiện tính toán trong một khung linh hoạt.

Hàm onTransfer trong hệ thống JAM cũng có trạng thái, cho phép nó sửa đổi trạng thái của dịch vụ. Nó có khả năng kiểm tra trạng thái của các dịch vụ khác và sửa đổi trạng thái của chính nó. Tính năng này tạo điều kiện giao tiếp giữa các dịch vụ, mặc dù theo cách không đồng bộ.

Không giống như nhiều nền tảng hợp đồng thông minh nơi các tương tác diễn ra đồng bộ, trong JAM, tương tác giữa các thành phần được đóng gói (chẳng hạn như hợp đồng thông minh hoặc dịch vụ trong trường hợp này) xảy ra không đồng bộ. Tin nhắn và token được gửi cùng nhau và tại một số thời điểm trong cùng chu kỳ thực hiện sáu giây, chúng được xử lý bởi dịch vụ nhận. Không có đường dẫn trở lại ngay lập tức; nếu cần có đường dẫn trở lại, dịch vụ gửi phải bắt đầu một quá trình truyền khác hoặc sửa đổi trạng thái của nó theo cách mà dịch vụ nhận sau này có thể diễn giải.

Cả Accumulate và onTransfer đều được thiết kế để thực thi song song, cho phép Accumulate và chuyển giao các dịch vụ khác nhau diễn ra đồng thời. Thiết kế này mở ra khả năng cải tiến trong tương lai, chẳng hạn như phân bổ gas đầu vào vượt quá 10 mili giây hiện tại. Về lý thuyết, lõi thứ cấp có thể được sử dụng để thực hiện một số Tích lũy nhất định, giúp chúng sử dụng nhiều gas hơn.

Như đã nêu trong Sách trắng Polkadot ban đầu, Polkadot chủ yếu được tùy chỉnh cho một hồ sơ dịch vụ cụ thể: cung cấp Chuỗi. Để triển khai dịch vụ này, Polkadot đã phát triển hai thành phần phụ quan trọng:

• Hệ thống sẵn có dữ liệu phân tán

• Một hệ thống cung cấp kiểm toán và đảm bảo cho việc tính toán (tức là hệ thống optimistic rollup với các đảm bảo bảo mật mạnh mẽ)

So với Polkadot , JAM có ít tùy chọn mặc định hơn và cung cấp mức độ trừu tượng và khái quát hóa cao hơn. Điều này giúp việc tận dụng các thành phần cơ bản dựa trên sở thích cá nhân trở nên dễ dàng hơn.

JAM hoạt động theo cách không được phép, tương tự như Chuỗi hợp đồng thông minh, cho phép các cá nhân tải lên và thực thi mã dự định. Ngoài ra, nó lưu trữ dữ liệu, cho phép tra cứu tiền ảnh và quản lý trạng thái, tương tự như hệ thống khóa-giá trị. Vì JAM thiếu cơ chế chấp nhận giao dịch trực tiếp nên khối gốc của JAM chứa một dịch vụ tạo điều kiện thuận lợi cho việc tạo ra các dịch vụ mới.

Các dịch vụ trong JAM không có giới hạn xác định trước về số lượng mã, dữ liệu hoặc trạng thái. Khả năng của chúng được xác định bởi các yếu tố crypto; càng gửi nhiều token DOT thì khả năng dữ liệu và trạng thái càng lớn. Ví dụ: dịch vụ Chuỗi trên JAM tích hợp tất cả chức năng Polkadot 1.1 vào một dịch vụ duy nhất và các dịch vụ khác cũng có thể tận dụng hệ thống sẵn có phân tán của Polkadot , cũng như hệ thống tính toán kiểm toán và đảm bảo.

Thiết kế của PVM dựa trên kiến ​​trúc tập lệnh RISC-V (ISA), được biết đến vì tính đơn giản và linh hoạt. RISC-V ISA có một số ưu điểm:

1. Dễ dàng dịch sang các định dạng phần cứng phổ biến, chẳng hạn như x86, x64 và ARM.

2. Được hỗ trợ tốt bởi các công cụ như LLVM.

Bản thân PVM thể hiện sự đơn giản và bảo mật, có khả năng được đóng hộp cát và cung cấp nhiều đảm bảo thực thi. Nó mang tính quyết định, nhạy cảm với sự đồng thuận và dễ đo lường. So với các máy ảo khác, PVM thiếu độ phức tạp và các tùy chọn đặt trước quá mức.

WASM, mặc dù được tối ưu hóa cho các trường hợp sử dụng web nhưng cũng đặt ra những thách thức về quản lý ngăn xếp, đặc biệt là khi xử lý tính liên tục. RISC-V giải quyết vấn đề này bằng cách đặt ngăn xếp vào bộ nhớ, do đó tạo điều kiện thuận lợi cho việc xử lý tuần tự một cách tự nhiên mà không cần tăng thêm độ phức tạp.

Hơn nữa, PVM thể hiện tốc độ thực thi vượt trội khi chạy trên phần cứng truyền thống, đặc biệt là trên X64 và ARM, mang lại những lợi ích như đo sáng miễn phí, một lợi thế so với WASM.

Việc hỗ trợ tính liên tục của RISC-V sẽ thiết lập một tiêu chuẩn mới cho mã hóa mở rộng trên các nền tảng đa lõi như JAM. Kiến trúc song song không đồng bộ ngày càng quan trọng đối với mở rộng của nền tảng phần cứng và phần mềm, một xu hướng dự kiến ​​​​sẽ mở rộng sang blockchain và thuật toán đồng thuận.

SAFROLE là một thuật toán sản xuất khối giúp đơn giản hóa SASSAFRAS. Nó loại trừ một số thành phần có thể hữu ích cho Chuỗi. Vì vậy, Chuỗi có thể nhất quyết sử dụng SASSAFRAS thay vì SAFROLE. SAFROLE càng đơn giản càng tốt:

• Đảm bảo giảm thiểu các tùy chọn đặt trước nhiều nhất có thể để tối đa hóa các trường hợp sử dụng tiềm năng trong tương lai.

• Hãy đi theo bước chân của Sách vàng Ethereum và thực sự cố gắng triển khai càng nhiều càng tốt để thử và truyền bá kiến ​​thức chuyên môn.

Việc hiểu cách Polkadot 1.0 hoạt động từ đầu đến cuối là một thách thức. Với JAM, người có thể đọc và hiểu Sách Vàng sẽ có thể đọc và hiểu nhanh cách JAM hoạt động. Vì vậy, sự đơn giản là rất quan trọng.

SAFROLE là một thuật toán sản xuất khối dựa trên SNARK. Nó sử dụng SNARK vì tính chất nặc danh của nó. Và nó cung cấp khả năng sản xuất khối thời gian liên tục gần như hoàn toàn fork. Một số trường hợp về cơ bản có thể xảy ra fork chỉ xảy ra khi có sự phân chia mạng hoặc ai đó có hành động cố ý ác ý. Giá trị lớn của nặc danh không phải là giữ bí mật danh tính của người xác thực; trên thực tế, khi họ tạo ra một khối, họ vẫn tiết lộ danh tính của mình và điều này được thực hiện để đảm bảo tính bảo mật của chính cơ chế sản xuất khối, về cơ bản là để tránh thư rác. các cuộc tấn công.

Mạng của JAM sử dụng giao thức QUIC. Điều này cho phép kết nối ngang hàng trực tiếp giữa lượng lớn người xác thực. Do đó, hơn 1000 trình xác thực trên Polkadot có thể duy trì các kết nối liên tục với nhau mà không phải lo lắng về các sự cố ổ cắm có thể xảy ra. Vì JAM không xử lý các giao dịch nên về cơ bản không cần phải buôn chuyện. Trong các tình huống yêu cầu phân phối không phải là điểm-điểm hoặc trong một tập hợp con rất nhỏ các trình xác nhận, việc khuếch tán lưới được sử dụng, trong đó các trình xác thực được sắp xếp thành một lưới, các gói được gửi thành hàng và sau đó mỗi nút sẽ gửi nó tới tất cả các thành viên cột của nó.

Trong blockchain dựa trên trạng thái như Ethereum , tiêu đề của khối thường chứa gốc trạng thái sau, tóm tắt trạng thái được tính toán của tất cả các khối. Do đó, tiêu đề khối không thể được gửi cho đến khi tất cả các phép tính được hoàn thành. Tuy nhiên, một số tính toán có thể được thực hiện trước khi gửi tiêu đề khối, vì kết quả của chúng xác định tính hợp lệ của khối.

Tuy nhiên, JAM thực hiện một phương pháp khác, đặt các gốc tiền trạng thái trong tiêu đề khối thay vì đặt các gốc sau trạng thái. Điều này có nghĩa là trạng thái hiển thị trong tiêu đề bị trễ một khối. Kết quả là, các phép tính nhẹ chiếm khoảng 5% khối lượng công việc hoặc thời gian thực hiện của khối có thể được thực hiện và các khối có thể được phân phối ngay lập tức. 95% tính toán khối còn lại, chủ yếu là nhiệm vụ Tích lũy, có thể hoàn thành sau. Điều này cho phép khối tiếp theo được bắt đầu trước khi khối hiện tại được thực thi.

Phương pháp này cho phép sử dụng hiệu quả hơn thời gian giữa các khối. Trong cài đặt truyền thống, chẳng hạn như thời gian khối sáu giây của Polkadot , gốc trạng thái sau phải được cung cấp và chỉ có thể được tính toán một phần thời gian. Tuy nhiên, thông qua quy trình trong JAM, toàn bộ thời gian khối có thể được sử dụng một cách hiệu quả để tính toán, tối đa hóa hiệu quả.

Mặc dù việc sử dụng toàn bộ thời gian khối để tính toán có thể không lý tưởng vì nó có thể dẫn đến việc nhập khối bị bắt kịp và bị trì hoãn vĩnh viễn, nhưng phương pháp của JAM có thể kéo dài đáng kể thời gian tính toán so với các thiết lập truyền thống. Điều này có nghĩa là thời gian tính toán khối hiệu quả có thể đạt được khoảng ba đến ba giây rưỡi, đây là một cải tiến lớn so với các thiết lập hiện tại.

Một điểm khác biệt về kiến ​​trúc giữa JAM và Chuỗi chuyển tiếp là mức độ cố định của chức năng. Trong khi Chuỗi chuyển tiếp sửa một số thành phần, chẳng hạn như ngôn ngữ được sử dụng để xác định giao thức (WASM), JAM còn tiến xa hơn về vấn đề này. Ví dụ: nó chỉ ra các loại được sử dụng để mã hóa tiêu đề khối và sơ đồ băm, gây khó khăn cho việc thay đổi các khía cạnh này.

Tuy nhiên, JAM vẫn giữ được tính linh hoạt thông qua mô hình dịch vụ của mình, có thể so sánh với mô hình mà siêu giao thức WebAssugging trong Chuỗi chuyển tiếp đạt được. Trong mô hình này, trách nhiệm về nâng cấp được chuyển sang dịch vụ, giải phóng Chuỗi khỏi gánh nặng nâng cấp . Ba lý do chính hỗ trợ cho quyết định này bao gồm:

1. Ưu tiên sự đơn giản Việc duy trì Chuỗi không nâng cấp làm giảm đáng kể độ phức tạp.

2. Chuỗi chuyển tiếp có xu hướng giới thiệu chức năng phức tạp mà không loại bỏ chức năng cũ, điều này làm phức tạp mọi thứ. Vì nâng cấp rất dễ thực hiện nên có rất ít động lực để đơn giản hóa SDK cơ chất. Vì vậy, việc nhân rộng Polkadot trở nên không thực tế.

3. Các tham số cố định của JAM mang lại tiềm năng tối ưu hóa. Bằng cách hiểu rõ ràng về các nhiệm vụ cụ thể mà Chuỗi JAM phải thực hiện và có thể đặt các tham số cố định, việc tối ưu hóa trong các lĩnh vực như cấu trúc liên kết mạng và thời gian trở nên khả thi. Điều này trái ngược với bản chất nâng cấp cao của Chuỗi chuyển tiếp, trong đó những tối ưu hóa này phức tạp hơn do những thay đổi thường xuyên có thể được thực hiện sau lần nâng cấp .

Bất chấp những khác biệt này, JAM vẫn duy trì tính linh hoạt trong chức năng cấp ứng dụng như bán thời gian cốt lõi, đặt cược và quản trị, tất cả đều được quản lý trong dịch vụ. Ngoài ra, JAM giới thiệu một khái niệm mới bằng cách liên kết số dư token với các dịch vụ, tạo cơ hội điều chỉnh mô hình kinh tế mà không dễ đạt được trong Chuỗi nâng cấp hoàn toàn như Chuỗi chuyển tiếp.

Để đảm bảo rằng JAM đáp ứng được những mong đợi ban đầu, nỗ lực không ngừng bao gồm việc thiết lập một hoàn cảnh thử nghiệm toàn diện cho Chuỗi JAM. Thay vì chạy một mạng thử nghiệm quy mô nhỏ trên phần cứng không đáng tin cậy để quản lý chi phí điện toán đám mây, sáng kiến ​​này cần lượng lớn.

JAM Toaster được giới thiệu ở đây, về cơ bản là một nền tảng thử nghiệm cho các thử nghiệm quy mô lớn và đánh giá hiệu suất. Điều này giải quyết những thách thức trước đây gặp phải trong quá trình phát triển Chuỗi chuyển tiếp Polkadot , khi chúng tôi biết rằng việc vận hành các hiệu ứng nổi bật và động lực của mạng ở quy mô như vậy tỏ ra khó khăn. Những lần thử trước đây chỉ giới hạn ở vài chục nút trên mạng thử nghiệm và mạng Kusama , Kusama khả năng giám sát toàn diện do thiếu quyền truy cập vào nút xác thực. Ngược lại, các mạng thử nghiệm quy mô nhỏ không mô phỏng chính xác động lực của mạng khi triển khai quy mô lớn.

JAM Toaster nhằm mục đích thu hẹp khoảng cách này bằng cách cung cấp cái nhìn sâu sắc về toàn bộ mạng JAM, bao gồm 1023 nút . Nền tảng này tạo điều kiện thuận lợi cho việc nghiên cứu hành vi mạng và đặc điểm hiệu suất, cung cấp cho các nhà phát triển nhận xét có giá trị về hiệu suất dự kiến ​​của Chuỗi .

Trong ỨNG TÁC, việc đo điểm chuẩn hoặc kiểm tra hiệu suất có thể là tùy chọn. Mặc dù việc đo điểm chuẩn vẫn có thể được yêu cầu trong một số trường hợp nhưng hệ thống đo lường của JAM thường loại bỏ nhu cầu đo điểm chuẩn thường xuyên. JAM chạy trên hệ thống đo lường cho phép người dùng đánh giá khối lượng công việc tính toán sau khi hoàn thành. Ngoài ra, còn có một cơ chế lý thuyết để kiểm soát việc tính toán khi các khối được xây dựng.

Tuy nhiên, trong một số trường hợp, việc so sánh điểm chuẩn vẫn cần thiết. Ví dụ: khi đo lường quá thận trọng đối với một số trường hợp sử dụng nhất định, có thể cần phải đo điểm chuẩn để cải thiện hiệu suất. Ngoài ra, điểm chuẩn rất hữu ích cho nhiệm vụ yêu cầu thời gian thực hiện kéo dài để đảm bảo chúng không chạy quá lâu.

Tiếp theo là truyền thông điệp chuỗi Chuỗi (XCMP) và JAM yêu cầu hỗ trợ XCMP đầy đủ. Điều này là do trong Chuỗi chuyển tiếp, nếu tất cả Chuỗi truyền tất cả dữ liệu mọi lúc, thì nhiều dữ liệu hơn có thể được chuyển qua biên nhận ứng viên. JAM tuân theo các quy tắc nghiêm ngặt, ngay cả đối với các dịch vụ Chuỗi, bao gồm các hạn chế về truyền dữ liệu giữa các giai đoạn “Tinh chỉnh” và “Tích lũy”. Hiện tại, bằng cách sử dụng Truyền thông điệp Chuỗi chuyển tiếp ngang (HRMP), tất cả các tin nhắn đều đi qua Chuỗi chuyển tiếp, giới hạn tải trọng dữ liệu ở mức 4 kB trở xuống, điều này có thể không thực tế. Do đó, XCMP chỉ chuyển tiếp các tiêu đề tin nhắn qua Chuỗi trong khi dữ liệu tin nhắn thực tế được truyền ngoài Chuỗi, một cải tiến cần thiết và đã quá hạn lâu.

Về cơ bản, các hiệp định đóng gói trạng thái và logic, tương tự như hợp đồng thông minh và mỗi Chuỗi có nhiều phiên bản. Chúng tạo điều kiện thuận lợi cho việc trao đổi tin nhắn giữa các phiên bản và cho phép tương tác đồng bộ với Chuỗi. Giao thức này rất hữu ích trong các tình huống thiếu sự tin cậy giữa Chuỗi, chẳng hạn như chuyển token. Không giống như phương pháp hiện tại liên quan đến các trung gian dự trữ, Accord đơn giản hóa việc chuyển token trực tiếp giữa Chuỗi , loại bỏ sự cần thiết của các trung gian gây tổn hại đến lòng tin. Ngoài ra, Accord có thể hoạt động như một cơ chế chuyển tiếp XCM, đảm bảo tính toàn vẹn của tin nhắn ngay cả khi được chuyển tiếp qua bên trung gian bên thứ ba, do đó loại bỏ nhu cầu về đánh dấu xuất xứ rõ ràng.

Cuối cùng, JAM áp dụng phương pháp rộng hơn, ít được ưu tiên hơn để tận dụng cơ chế đồng thuận cơ bản, giúp triển khai các giải pháp sáng tạo hơn. Ví dụ: đối với nhiệm vụ phức tạp như Bằng chứng không tri thức , tính khả dụng phân tán sẽ trở nên thiết thực và hiệu quả hơn. Ngoài ra, JAM hỗ trợ mô hình tiêu thụ tài nguyên hỗn hợp, trong đó các gói công việc có thể chứa cả nhiệm vụ cần tính toán nhiều và các hoạt động cần nhiều dữ liệu. Bằng cách kết hợp các dịch vụ chuyên sâu lượng lớn với các dịch vụ yêu cầu tính khả dụng dữ liệu cao, JAM tối ưu hóa việc sử dụng tài nguyên của trình xác thực, từ đó giảm chi phí. Phương pháp linh hoạt này giúp việc kết hợp khối lượng công việc Chuỗi như tính khả dụng được phân phối và xác minh SNARK tiết kiệm chi phí hơn đồng thời tăng hiệu quả.

JAM được thiết kế để ưu tiên khả năng tương thích với Chuỗi Polkadot 1 hiện có. Mặc dù nó duy trì khả năng tương thích với SDK Polkadot nhưng Chức năng xác thực Polkadot (PVF) đã được di dời. Nó sẽ nhắm mục tiêu Máy ảo Polkadot (PVM), chứ không phải WebAssembly. Quá trình chuyển đổi này được tạo điều kiện thuận lợi bởi thực tế là PVM là một sửa đổi nhỏ của RISC-V, được chính thức xác định là mục tiêu của LLVM. Do đó, PVM có thể trở thành mục tiêu LLVM chính thức trước khi JAM được triển khai.

Ngoài việc là nơi lưu trữ Chuỗi, JAM còn giới thiệu những cải tiến đáng kể. Nó mang lại tiềm năng đơn giản hóa các nỗ lực đo điểm chuẩn và giảm bớt nhu cầu đo điểm chuẩn trong tương lai. Ngoài ra, JAM còn giới thiệu khái niệm về giao thức, hợp đồng thông minh đa phiên bản và đa phân đoạn để quản lý và thực thi các giao thức tương tác cụ thể giữa Chuỗi . Ngoài ra, hỗ trợ Truyền thông điệp chuỗi Chuỗi (XCMP) toàn diện là rất quan trọng, giúp loại bỏ các hạn chế về truyền thông tin giữa Chuỗi, điều này thường được hỗ trợ thông qua Nhắn tin chuỗi Chuỗi(XCM).

Về Agile Coretime, JAM duy trì khả năng tương thích với các thiết lập hiện có. Tuy nhiên, nó giới thiệu khả năng xác định thời gian cốt lõi không chỉ trên Chuỗi mà còn trên các nhóm gói công việc tùy ý. Tính linh hoạt này nâng cao tính linh hoạt và hiệu quả của việc phân bổ tài nguyên trong hệ sinh thái JAM.