Nghiên cứu Web3: Giao thức truyền chuỗi chéo XCMP
PolkaBase
2020-09-10 09:02
本文约6816字,阅读全文需要约27分钟
Trong mạng Polkadot, chúng ta cần gửi thông tin cho một số thực thể (entity), trước tiên chúng ta hãy phân loại ngắn gọn các loại thực thể này: (1) người dùng, (2) người thu thập, (3) người xác minh
Mục lục
  • Mục lục

  • nhắn tin liên chuỗi

Giao thức tin đồn đơn giản cho định tuyến hàng đợi ICMP

trên cấu trúc cây mới (lá) B

Khai báo tiêu đề khối chuỗi mới của nút (ngang hàng) k

k từ mô-đun t đang ở trong Hàng đợi tin nhắn m

Định nghĩa nút lớp ngang hàng (ngang hàng) k trên 〖được phép〗_k (m)

  • Định kỳ

  • cải tiến trong tương lai

Nhắn tin xuyên chuỗi XCMP

Trong mạng Polkadot, chúng ta cần gửi thông tin cho một số thực thể (entity), trước tiên chúng ta hãy phân loại ngắn gọn các loại thực thể này: (1) người dùng, (2) người thu thập, (3) người xác minh

Trong mạng Polkadot, chúng ta cần gửi thông tin cho một số thực thể (entity), trước tiên chúng ta hãy phân loại ngắn gọn các loại thực thể này: (1) người dùng, (2) người thu thập, (3) người xác minh

1. Người dùng - tạo giao dịch và cung cấp thông tin cho chuỗi dù hoặc chuỗi chuyển tiếp

2. Collator - Được liên kết với một parachain cụ thể. Họ chịu trách nhiệm tổ chức và đóng gói dữ liệu giao dịch của parachain thành các khối để tạo chứng chỉ hợp lệ và gửi chúng cho người xác thực trên parachain như một phần của khối tiếp theo. Hai liên kết tiếp theo liên quan đến tính hợp lệ là một phần của các quy tắc cơ bản của mạng Polkadot, nhưng cách thực hiện các hoạt động phân loại cụ thể được lựa chọn độc lập bởi parachain.

3. Trình xác thực - thuộc chuỗi chuyển tiếp và tuân theo các quy tắc của mạng Polkadot. Các tập hợp con khác nhau của trình xác thực được chỉ định cho các parachain khác nhau để xác thực các chuỗi đó, do đó chúng tôi gọi các tập hợp con này là "trình xác thực parachain". Họ cũng sẽ sắp xếp thông tin giao dịch và gửi nó đến chuỗi chuyển tiếp.

Tiếp theo, chúng ta cần hiểu một số giao thức con giữa các thực thể này, mỗi giao thức con phục vụ cho việc trừu tượng hóa tương ứng của việc thực hiện các giao dịch:

1. Gửi giao dịch

Khi có quyền truy cập thực thể liên quan, người dùng cần tìm thực thể liên quan để gửi giao dịch.

2. Đối chiếu chuỗi parachain

Trình thu thập chuỗi song song thu thập và đóng gói thông tin giao dịch thành các khối và dữ liệu trong khối đến từ chuỗi bên ngoài bên ngoài phạm vi của mạng Polkadot được chọn bởi mỗi chuỗi song song.

3. Chứng thực khối parachain

Bộ đối chiếu cũng tạo dữ liệu chứng thực khác và gửi nó tới bộ xác thực của parachain. Mục tiêu cuối cùng của việc này là để những người xác thực parachain kiểm tra hiệu quả xem mỗi khối parachain có đáp ứng chức năng xác minh trên chuỗi của nó hay không. Để tạo dữ liệu bằng chứng, người đối chiếu cũng cần dữ liệu được gửi lại bởi người xác nhận parachain trước đó trên chuỗi chuyển tiếp.

4. Giao thức chuỗi chuyển tiếp

Trình xác nhận chuỗi parachain chứng thực tính hợp lệ của bất kỳ khối parachain nào đã được gửi và phân phối các bằng chứng này cho các trình xác thực khác để đạt được sự đồng thuận. Sau đó, tất cả các trình xác thực tổ chức và đóng gói các khối đã được chứng minh và thông tin giao dịch trên chuỗi chuyển tiếp thành các khối chuỗi chuyển tiếp và hoàn thiện các khối.

5. Nhắn tin liên chuỗi

Sau khi các khối chuỗi chuyển tiếp được hoàn thiện và dữ liệu này được chuyển giao lại cho parachain, parachain sẽ kiểm tra xem các khối này có chứa thông tin mới từ các parachain khác hay không và nếu có, sẽ sửa chữa và phản hồi.

(Parachain synchronisation)

6. Tích hợp thông tin của parachains

Khi collator kết nối lần đầu hoặc ngắt kết nối trong một thời gian dài, nó phải truy xuất lại và xác minh trạng thái mới nhất của parachain sau khi kết nối được khôi phục. Nội dung xác minh bao gồm thông tin giao dịch được gửi tạm thời và thông tin về trạng thái mới nhất của parachain chuỗi tiếp sức.

7. Tích hợp thông tin của chuỗi chuyển tiếp

Trong phần mô tả ở trên, chúng tôi đã giải thích các chi tiết liên quan trong phần tóm tắt và cố gắng giữ cho nó hợp lệ ngay cả khi các chi tiết này thay đổi. Khi viết chương trình, chúng tôi nhận thấy rằng trong số các dịch vụ mà lớp mạng Polkadot cần cung cấp, các giao thức con (3-5) và 7 vẫn là những thành phần được yêu cầu nhiều nhất và phức tạp nhất và dự kiến ​​sẽ được giữ lại.

XCMP

tiêu đề phụ

Truyền thông tin liên chuỗi: Thu thập dữ liệu hàng đợi đầu ra

Mỗi khối parachain trong Polkadot tạo ra một danh sách các tin nhắn có thể trống cho mọi khối khác. Chúng được gọi là "hàng đợi đi ra". E_(x,y)^B được sử dụng để biểu thị hàng đợi đi ra từ chuỗi x đến chuỗi y trong khối B. R(E_(x,y)^B) Đây là gốc hàm băm của Merkle Patricia trie[], thu được bằng cách vẽ một chương trình dendro cho E_(x,y)^B trong dữ liệu thông báo.

Các tin nhắn chưa được xử lý được gửi đến một chuỗi đang chờ xử lý sẽ được xử lý trong khối tiếp theo của chuỗi đó. Nếu không có khối mới nào được tạo trên chuỗi trong một khoảng thời gian, thông báo có thể bắt đầu chồng chất.

Các nút đối chiếu và các nút đầy đủ trên parachain p đã thực thi tất cả các khối trên parachain đó và nên biết tất cả các khối B và E_(p,y)^B trong chuỗi x

Tập hợp các điểm truy cập của khối đi ra trên chuỗi song song p trên khối B là:

Gốc bộ sưu tập xâm nhập của khối là

Tổng mục nhập tích lũy (đầu vào) của khối B trên parachain p có thể được xác định bằng hàm đệ quy:

Đây là một khối bao gồm tất cả các lần xâm nhập từ khối B đến từng chuỗi song song đến từng khối trong chuỗi p

Parachains phải chạy 〖Ingress〗_(B,P) sau 〖ingress〗_(parent(B),p) và mọi dữ liệu cũng như hướng dẫn từ 〖Ingress〗_(B,P) phải được chạy .

Mỗi parachain có một giá trị hình mờ p được tạo bởi chuỗi chuyển tiếp phản ánh hoạt động xâm nhập được chạy gần đây nhất. Ban đầu được thiết lập là Genesis, để xác định cấu trúc chứa tất cả các thông báo nổi bật dưới dạng parachain, chúng tôi giới thiệu các mục nhập đang chờ xử lý, được xác định bởi các hàm đệ quy.

Các gốc đang chờ xử lý R(P_INGRESS (B,P)) này cũng có thể được tính gần đúng là R(T_INGRESS (B,P)). Chuỗi ứng cử viên parachain cho phép xây dựng P_INGRESS (B,P ) với bất kỳ tiền tố nào.

CandidateReceipts

Tất cả thông tin về parachain trong thời gian chạy đều đến từ

Nguồn ứng cử viên này được tạo bằng cách xác thực các khối ứng cử viên parachain và được đưa vào các khối chuỗi chuyển tiếp. Thí sinh có nhiều lĩnh vực. Dưới đây là một số cái có liên quan:

  • Vec<(ParaId, Hash)>

Rễ đi ra:

Khi khối chuỗi chuyển tiếp B được bao gồm trong parachain p, mỗi giá trị băm được ghép nối với parachain y duy nhất là R(E_(p,y)^B)

  • watermark p

Khi dữ liệu nhận được dành cho parachain p, một

giá trị. Bộ thực thi coi giá trị mà nó nhận được từ chuỗi ứng cử viên của parachain gần nhất là giá trị hiện tại. Giá trị ban đầu của B trong bất kỳ khối nào chứa ứng cử viên ít nhất phải cao bằng giá trị trước đó của hình mờ p.

(cướp: lối ra đang chờ xử lý không trống trong danh sách trống không được phép)

Cả người xác minh và người thu thập đều cố gắng thu thập thông tin hàng đợi khối trên khối B hoặc người xác minh chỉ gọi 〖Ingress〗_(B,P) và tìm kiếm các tin nhắn có liên quan trong nhóm lan truyền, chờ đợi các tin nhắn chưa được phát hành. Mục tiêu của bộ đối chiếu trên P là xây dựng trên chuỗi chuyển tiếp gốc B, để có được tiền tố của P_INGRESS (B,P) càng nhiều càng tốt.

R(P_INGRESS (B,Cách dễ nhất là sử dụng . Tin nhắn được chuyển từ mạng parachain này sang mạng parachain khác. Nếu có một nút chung giữa hai mạng này đang phát tin nhắn, thì tin nhắn sẽ khiến liên kết song song đang nhận tin nhắn nhận được tin nhắn của nó. Tuy nhiên, nếu người xác thực của parachain mục tiêu nhận ra rằng thông báo không được truyền đến người nhận của parachain, thì họ sẽ yêu cầu lại thông báo từ nút trình xác nhận của parachain đã gửi tin nhắn, sau đó họ sẽ nhận được thông báo đó trên bản thân parachain.thiết bị để nhân giống.

P)) có sẵn ở mọi khối B và parachain p khi chạy.

Tính khả dụng của parachain p và khối B là do p và B là danh sách đầu vào của các gốc đầu vào đang chờ xử lý cho khối đó và mỗi danh sách và gốc được ghép nối đầu tiên với số khối được định tuyến. Bỏ qua R(∅) khỏi danh sách xâm nhập và bỏ qua danh sách trống và sắp xếp theo số khối tăng dần. trong đó tất cả các số khối đều nhỏ hơn num(B) và đề cập đến các khối trong cùng một chuỗi.

  • fn ingress(B, p) -> Vec<(BlockNumber, Vec<(ParaId, Hash)>)>

Mã giả trong RUST (TODO: Transcribe to LaTeX)

  • fn egress(B, p) -> Vec<(BlockNumber, Vec<(ParaId, Hash)>)>

Dữ liệu từ hàng đợi đi ra cho một B và p nhất định vẫn có sẵn trong thời gian chạy, tuân theo các ràng buộc giống như danh sách vào w.r.t. sắp xếp thứ tự và bỏ qua các danh sách trống. ParaId ở đây là chuỗi nhận và trong hàm nhập (ingress) là chuỗi gửi.

Giả sử rằng cấu trúc cây rời khỏi khối là khối parachain mới nhất trong chuỗi chuyển tiếp.

Chúng tôi đưa ra các giả định sau về các nút:

1. Trạng thái khối của các lá ở cuối cấu trúc cây có sẵn, nhưng không thể đảm bảo trạng thái của khối cũ

2. Có thể mong đợi rằng các bộ đối chiếu và các nút đầy đủ trên parachain sẽ giữ lại tất cả các khối đã được thực thi trên parachain.

3. Trình xác thực không cần giữ bất kỳ khối nào. Cũng xin lưu ý rằng thông tin có thể được khôi phục từ các đoạn mã xóa được lưu bởi trình xác thực

Giả sử chúng ta xây dựng trên một hệ thống thừa nhận giao thức tin đồn, các đồng nghiệp có thể giao tiếp với nhau về điểm cuối cấu trúc cây (lá) mà họ nghĩ là tốt nhất

Chương này mô tả một giao thức tin đồn giới hạn để truyền các hàng đợi của các bản tin ICMP (xem phần Tổng quan để biết định nghĩa).

  • fn ingress(B, p) -> Vec<(BlockNumber, Vec<(ParaId, Hash)>)>

  • fn egress(B, p) -> Vec<(BlockNumber, Vec<(ParaId, Hash)>)>

  • BlockNumber -> BlockHash

Vì lối vào đã được gọi trên khối B, chúng ta có thể dễ dàng đặt

để chuyển đổi

Tin nhắn bắt đầu ở trạng thái không định tuyến và kết thúc ở trạng thái định tuyến

Chúng tôi đề xuất xác định một hệ thống lan truyền tin đồn

  • struct Queue {    root: Hash,    messages: Vec,    }

Thông báo về mô-đun này có dạng

Chúng tôi giữ thông tin địa phương như:

  • MAX_CHAIN_HEADS

1. 〖leaves〗_k là danh sách hàm băm tốt nhất cho các điểm cuối (lá) của cấu trúc cây khối DAG của chúng tôi cần thực thi mã

2. 〖leaves〗_k, đối với mỗi peer k, danh sách mới nhất tốt nhất cần thực thi mã MAX_CHAIN_HEADSDAG giá trị băm của khối (dựa trên những gì họ đã gửi cho chúng tôi)

3. leafTopics(l)→{queueTopic(h)} có nghĩa là gốc h chưa được mở rộng trên chuỗi song song trên nút cây l trên tất cả các cấu trúc cây (lá)

4.expectedQueues(t)→H chỉ ra quá trình dẫn xuất của hàm băm tương ứng của tất cả các mô-đun gọi và t∈∪l_(∈leaves)leafTopics(l) trong tất cả các mục

trên cấu trúc cây mới (lá) B

1. Nâng cấp cấu trúc cây (lá), mô-đun cây (leafTopics) và hàng đợi dự kiến ​​(thử nghiệm điểm chuẩn chưa được thực hiện nhưng ước tính thận trọng sẽ có thời gian chạy là 100 mili giây)

2. Gửi cấu trúc cây (lá) mới của cùng một lớp

3. Nếu bộ thu của chuỗi song song p thực thi mã egress(B,p) trực tuyến. Đối với bất kỳ gốc hàng đợi tin nhắn đã biết nào chưa được truyền bá, chúng tôi sẽ đặt thông báo Hàng đợi tương ứng vào nhóm truyền bá.

Khai báo tiêu đề khối chuỗi mới của nút (ngang hàng) k

1. Nâng cấp cấu trúc cây (lá) 〖lá〗_k

2. Để đáp ứng yêu cầu của ∀H∈leaves ∩ 〖leaves〗_k, mỗi t trong BroadcastTopic(k,t) được ánh xạ trên leafTopics(H)

k từ mô-đun t đang ở trong Hàng đợi tin nhắn m

  • good(m)

chúng tôi xác định chức năng

Là một tiêu chuẩn tự tin cục bộ cục bộ (local Acceptance criteria).

  • root

gốc băm của tin nhắn

Trên chức năngexpectedQueues(t) được xác định, gốc thực của thông báo đã cho bằng gốc

Nếu hàm good(m) chứng minh rằng k dương, hãy đặt m vào nhóm lan truyền, nếu không, hãy chứng minh rằng m không khả dụng, điều này hữu ích cho việc canh tác tập hợp ngang hàng.

Định nghĩa nút lớp ngang hàng (ngang hàng) k trên 〖được phép〗_k (m) và Thông báo xếp hàng m trên mô-đun t

Nếu tin nhắn k được gửi cho chúng tôi trước khi chúng tôi gửi xong tin nhắn, tin nhắn k sẽ bị từ chối. Ngược lại, nếu sau

∃l∈leaves∩〖〖leaves〗_k|t∈leafTopics(l)∃l∈leaves∩〖leaves〗_k | t∈leafTopics(l), thì tin nhắn k được cho phép và các phương thức khác bị cấm.

Định kỳ

Ngoại trừ các hàng đợi mong đợi, chúng ta cần đánh dấu tất cả các mô-đun là các mô-đun đã hết hạn và xóa chúng trong vùng lan truyền. Trên thực tế, các thao tác như vậy được thực hiện cứ sau vài giây. Điều này ngăn nhóm nhân giống của chúng tôi phát triển vô thời hạn.

Quyết định chỉ truyền bá các tin nhắn chưa được định tuyến tới những người có cùng quan điểm về bản mod hiện tại có thể gây tranh cãi, nhưng một số điều kiện tiên quyết mà chúng tôi đưa ra đã thể hiện khá rõ quan điểm này.

Đầu tiên, chúng tôi không muốn nút phải xử lý vô số thông báo, điều đó có nghĩa là nút H trong queueTopic(H) không xác định được vì có vô số H như vậy. Thứ hai, các nút không phải thực hiện nhiều công việc để quyết định có truyền một thông điệp tới một đồng nghiệp cụ thể hay không. Giả sử lá∩〖lá〗_k=∅, nhưng một số mục của 〖lá〗_k là mã nguồn của lá

(tổ tiên). Ta phải chạy mọi l ∈ 〖lá〗_k trong O(n) để chứng minh. Sau đó, chúng tôi phải tìm hiểu xem một tin nhắn đã cho có bị hủy định tuyến trên khối trước đó hay không. Chúng tôi ngây thơ nghĩ rằng nếu một tin nhắn vẫn chưa được định tuyến trên một số khối sau này trong cùng một chuỗi, thay vì được định tuyến trong một chuỗi trước đó, thì điều đó khó có thể xảy ra nhưng trạng thái của chuỗi có thể là khôi phục lừa đảo tại nút của con người.

Vì trạng thái chuỗi giả định không có sẵn từ các khối trước đó, nên chúng tôi không có cách nào tốt để xác định xem có thực sự gửi một đầu ra đến một ngang hàng của khối trước đó hay không. Trong phần cải tiến trong tương lai, chúng tôi sẽ thảo luận về việc nới lỏng giới hạn này bằng cách mở rộng quy mô thành một số nguồn gốc (tổ tiên) cố định.

Tuy nhiên, chỉ hợp lý khi truyền tới các nút (ngang hàng) đã được đồng bộ hóa với cùng một chuỗi, giả sử như sau (một số kinh nghiệm nhưng hợp lý, nhưng cũng có khả năng được đánh giá quá cao):

1. Các khối hợp lệ mới được phát hành trong khoảng thời gian trung bình ít nhất là 5 giây (mục tiêu của chúng tôi thực tế là 10-15 giây)

2. Thời gian lan truyền của khối trong phần "hữu ích" của cấu trúc lan truyền tin đồn là trong vòng 2 giây.

3. Các đối tượng liền kề trong cấu trúc lan truyền tin đồn có độ trễ nhỏ hơn hoặc bằng 500ms

4. Tuyên truyền thông điệp có ý nghĩa trước khi đồng bộ với người đứng đầu DAG có thể không đáng

Giá trị thực tế gần như chắc chắn sẽ tốt hơn. Tin tốt là không phải tất cả các khối đều phải được lan truyền trong một thời gian khối - khi thời gian trôi qua, người tham gia ngày càng có thể nhận được các tin nhắn sớm hơn. Đây là một chương trình mà tất cả những người tham gia đều nhìn thấy tất cả các tin nhắn. Nó gần như chắc chắn sẽ không mở rộng ra ngoài một số chuỗi ban đầu, mà thay vào đó sẽ hoạt động đúng chức năng như một giao thức khởi động.

tiêu đề phụ

Tổng quan về Định tuyến XCMP

Để gửi tin nhắn từ một parachain (parachain gửi) đến một parachain khác (parachain nhận) theo thiết lập, các bước sau đây sẽ được thực hiện.

Tin nhắn là đủ khi nút đầy đủ của parachain gửi cũng là một phần của miền của parachain nhận

Trình xác thực parachain của parachain nhận không phát hiện ra rằng thông báo được lan truyền và sau đó nó trực tiếp yêu cầu thông báo từ trình xác thực parachain của parachain gửi (gửi PV thời gian thực). PV của parachain gửi chịu trách nhiệm giữ cho tin nhắn có sẵn. Trình xác minh parachain gửi parachain trực tiếp gửi tin nhắn đến PoV của parachain nhận, và cuối cùng PV của parachain nhận phát tán tin đồn (tin đồn) về tin nhắn trong mạng parachain nhận.

tiêu đề phụ

cải tiến trong tương lai

1. Phần trên mô tả lý do tại sao không nên truyền hàng đợi đầu ra một cách tùy tiện vào lớp ngang hàng, nhưng một khi chúng tôi đồng bộ hóa và tuân theo quy trình sản xuất khối thông thường, chúng tôi có thể theo dõi hợp lý tất cả các cây Mã nguồn cuối cùng (tổ tiên) α của trúc (lá). Giá trị hợp lý ban đầu của α phải nhất quán với giá trị gốc và lấy 1. Điều này có thể mang lại cho chúng tôi 90% mức tăng mà chúng tôi cần, đơn giản vì có hiện tượng "nói lắp" khi yêu cầu giao điểm của bộ cây và hai đồng nghiệp cần Cập nhật cho nhau thông tin về các khóa con mới.

2. Mở rộng định nghĩa của E_(x,y)^B có thể cho phép kiểm tra lẫn nhau giữa các chuỗi. Ví dụ: parachain y có thể yêu cầu chuỗi chuyển tiếp không định tuyến tin nhắn từ x tại khối B (và sau đó yêu cầu nó bắt đầu định tuyến lại tại khối B'). Đối với bất kỳ khối nào giữa B và B', chúng tôi sẽ có thời gian chạy là E_(x,y)^b=∅ khi bỏ qua x của b trên Biên nhận Ứng viên. Trên thực tế, vì bộ thực thi chỉ xử lý hàm băm gốc của hàm băm, nên nó thực sự chỉ bỏ qua R(E_(x,y)^b) khỏi biên nhận ứng viên và đặt nó thành R(∅)

3. Mở rộng quy mô để hỗ trợ các cấu trúc liên kết thông minh hơn, nơi không phải ai cũng có thể nhìn thấy mọi thứ. Có lẽ việc có hai loại mảng chủ đề (Topics), (B, (B,〖chuỗi〗_từ)) dựa trên mảng chủ đề (Topics) và mod dựa trên (B,〖chuỗi〗_to) sẽ cải thiện khả năng sử dụng của bản mod này.https://github.com/sipa/minisketch4. Sử dụng một số loại đối chiếu thiết lập thông minh (ví dụ:

) để giảm thiểu băng thông lan truyền tin đồn.

5. Khuyến khích phân phối theo cách tương tự như các khoản thanh toán vi mô xác suất.

6. Nút trình xác thực parachain sẽ giữ hàng đợi đầu ra cho đến khi được xác nhận rằng thông báo đã được chứa. Đây là một nhược điểm khi hai mạng parachain không có các nút đầy đủ giống hệt nhau và tin nhắn không đến qua trò chuyện. Nút xác thực parachain của parachain nhận sẽ nhận thấy thông báo bị thiếu và yêu cầu nút xác thực parachain của chuỗi gửi cho thông báo. Khi họ nhận được yêu cầu đó, nó sẽ truyền qua mạng parachain của người nhận.

Tất cả thông tin mà chuỗi khối có đối với logic nghiệp vụ đều ở dạng Biên nhận ứng viên. Người ký khối có thể gửi tối đa một Biên nhận Ứng viên từ mỗi parachain trong khối (thực tế, chỉ những chuỗi được chứng thực bởi nhiều trình xác thực, mặc dù giả định này không liên quan ở đây).

Biên soạn / tàng hình Yao

PolkaBase
作者文库