Ý tưởng chính đằng sau rapidblocks là nếu chúng ta có thể xây dựng các khối mà không có sự phụ thuộc giữa các khối , chúng ta có thể tăng tốc thời gian xử lý , giảm thời gian bao gồm giao dịch và mở rộng quy mô sản xuất Block đáng kể.
Nguyên nhân chủ yếu là:
- chúng ta có thể làm cho "tổ chức lại" rẻ hơn: chúng ta có thể chỉ cần bỏ qua một số rapidblock mà không cần phải tổ chức lại tốn kém . (Liệu nó có thực sự rẻ hơn nhiều hay chỉ rẻ hơn một Bit thì vẫn chưa rõ.)
- chúng ta có thể cho phép xây dựng các khối độc lập như vậy gần như song song . Gần như vậy, vì chúng ta cần phải sắp xếp các nhà xây dựng và có một lượng nhỏ luồng thông tin.
Tất nhiên, điều này có cái giá của nó, vì các khối thực sự cần phải phụ thuộc vào nhau theo một cách nào đó. Chúng ta sẽ tìm hiểu về điều này ở phần cuối.
Xin hãy coi bài đăng này như một bài viết Xả tâm trí và khởi đầu cho cuộc thảo luận hơn là một thiết kế hoàn thiện. Mô tả ở mức cao, bỏ qua nhiều chi tiết, có thể khiến toàn bộ ý tưởng trở nên không khả thi trong thực tế.
Những thông tin đầu tiên về ý tưởng này xuất hiện trong một phản hồi cho bài đăng trên BAL .
Làm thế nào để xây dựng các khối “độc lập”
Trạng thái đã sửa đổi
Giả sử người xây dựng Block i+1 biết tất cả các địa chỉ (hoặc cặp <địa chỉ, khóa lưu trữ>) nơi trạng thái được Block i sửa đổi.
Bây giờ nó có thể xây dựng một Block chỉ dựa trên phần trạng thái không bị Block i sửa đổi. Nói cách khác, nó có thể xây dựng nó trên phần sau trạng thái "cũ" của Block i-1, điều này cũng có nghĩa là:
- Block i có thể được "bỏ qua" khỏi chuỗi mà không làm mất Block i+1
- người xây dựng Block i+1 không cần phải thực hiện Block i trước khi xây dựng
- nó thậm chí không cần biết trạng thái thay đổi của Block i
Trạng thái đã truy cập
Bây giờ giả sử người xây dựng Block i+1 biết tất cả các địa chỉ (hoặc cặp <addresses,storagekey>) đã được Block i truy cập (đọc hoặc ghi). Với thông tin này, nó có thể xây dựng một Block thậm chí còn mạnh hơn, có thể song song hóa về mặt logic với Block i.
- Block i+1 không phụ thuộc vào Block i
- Block i không phụ thuộc vào Block i+1
Điều này cho phép chúng ta tổ chức lại "chuỗi" dễ dàng hơn nữa vì thứ tự thực hiện không quan trọng.
Tất nhiên, người đọc nhận thấy rằng cả hai giả định 1 và 2 đều đúng cho đến ngày nay. Người xây dựng Block của chúng tôi biết tất cả các địa chỉ này. Vậy chúng ta đang nói về điều gì?
Có hai điểm quan trọng cần lưu ý ở đây:
- a, trong khi người xây dựng Block tiếp theo có kiến thức này, chúng tôi không cung cấp nó một cách hiệu quả , dẫn đến thời gian khe dài hơn
- b, trong khi người xây dựng Block tiếp theo có kiến thức này, chúng ta không thực thi tính độc lập Block , điều này sẽ dẫn đến việc tổ chức lại thường xuyên hơn và tốn kém hơn nếu chúng ta giảm thời gian khe cắm.
Nhưng điều này thật điên rồ, các khối hiện phụ thuộc vào Block trước đó, đúng không?
Đúng, nhưng chỉ là một phần nhỏ trong số đó. Điều thú vị là hơn 90% giao dịch trong một Block thông thường dường như chứa các giao dịch không phụ thuộc vào Block trước đó. Để biết thêm chi tiết về trạng thái hiện tại của các phụ thuộc giữa các khối, hãy xem bài đăng này về sự nóng lên .
Với tiền đề này, chúng ta hãy xem những công cụ tiềm năng nào mà chúng ta có thể sử dụng để thực hiện repidblock.
Các công cụ
BAI và BMI
Nguồn cảm hứng chính cho những ý tưởng này là việc khám phá nhiều dạng thay đổi trạng thái Block và danh sách truy cập, còn gọi là BAL, trong một tác phẩm tuyệt vời của Toni .
Có thể dễ dàng thấy rằng điều kiện 1 của chúng ta là phần danh sách địa chỉ của thay đổi trạng thái sau khối của BAL. Chúng ta hãy gọi đây là BMI, chỉ số sửa đổi trạng thái Block .
Điều kiện thứ hai của chúng tôi thay vào đó là ánh xạ BAL mà không có thông tin trạng thái trước hoặc sau. Hãy gọi đây là BAI, Chỉ số truy cập cấp khối.
Lưu ý: có lẽ chúng ta nên gọi đây là vị trí lưu trữ / vị trí ghi, nhưng L của Locataion đã được sử dụng cho L trong Danh sách
Do đó, nếu chúng ta có thể chuyển tiếp nhanh một trong những điều này đến trình xây dựng tiếp theo và chúng ta sẽ tận dụng lợi thế của việc tổ chức lại rẻ hơn được phép theo tính độc lập Block , chúng ta có thể giảm thời gian khe. Trong Ethereum, chúng ta không thể chỉ chuyển tiếp nhanh điều này đến trình xây dựng tiếp theo, chúng ta cần gửi nó đến toàn bộ mạng. Ngay cả khi chúng ta biết trình xác thực tiếp theo, chúng ta không biết nó ở đâu trong mạng và chúng ta không có định tuyến dựa trên ID trình xác thực, vì những lý do hiển nhiên.
Tuy nhiên, chúng ta có thể nghĩ đến việc ưu tiên BAI (lớn hơn) hoặc BMI (nhỏ hơn) trên mạng, giảm thời gian khe cắm.
BAF và BMF
Sẽ còn tuyệt hơn nữa nếu chúng ta có thể nén BAI hoặc BMI, chẳng hạn, thành một gói IP duy nhất và chuyển tiếp nhanh trong mạng. Điều này có khả năng cho phép chúng ta khuếch tán thông tin trong toàn bộ mạng chỉ trong 300ms. Một cách chúng ta có thể thử để đạt được điều này là sử dụng bộ lọc Bloom. Xem bài đăng BAF của tôi để biết thêm chi tiết.
Cấu trúc “chuỗi” rapidblock
Công cụ cuối cùng của chúng tôi là cấu trúc “chuỗi” mới. Trên thực tế, cấu trúc cơ bản không phải là chuỗi mà là DAG bị hạn chế, nhưng chúng tôi có thể dễ dàng “tuyến tính hóa” nó thành dạng xem chuỗi nếu ai đó thực sự cần. (Và tôi nghĩ đây là một phần quan trọng để tương thích và là sự giới thiệu tiến hóa cuối cùng của các ý tưởng ở đây).
Tất nhiên Block phải có sự phụ thuộc. Nhưng chúng không nhất thiết phải phụ thuộc vào khối đã xây dựng trước đó. Nếu chúng ta có thể giảm thời gian khe cắm, thực thi tính độc lập với khối trước đó và cho phép nó khỏi khối trước đó, thực sự có thể có cùng kết quả.
Những gì chúng tôi đã tạo ra ở trên là một đường ống sản xuất Block có thể xây dựng
- các khối độc lập lẫn nhau
- bất kỳ khối nào trong số này đều có thể được loại bỏ độc lập khỏi "chuỗi", mà không ảnh hưởng đến tính hợp lệ của Block khác.
- các khối được sắp xếp chặt chẽ nhưng không phụ thuộc vào trạng thái
- nếu Block
bdựa trên BAF hoặc BMF của Blockathì bất kỳ khối nào trong số này vẫn có thể được loại bỏ khỏi chuỗi một cách dễ dàng, nhưng chúng không thể được thực thi theo thứ tự ngược lại hoặc song song, vìacó thể truy cập trạng thái đã đượcbsửa đổi
- nếu Block
Rõ ràng, Consensus trở nên phức tạp hơn, ít nhất là có vẻ như vậy. Chứng thực không chỉ trở nên nhanh hơn một cách kỳ diệu chỉ vì chúng ta xây dựng các khối thường xuyên hơn. Nhưng việc tổ chức lại rẻ hơn nhiều và các khối có thể được xây dựng với tần suất cao hơn. Để nói rõ, tôi vẫn chưa có quan điểm rõ ràng về cách thức hoạt động của nó, nhưng tôi nghĩ chúng ta có thể tạo ra một cơ chế Consensus được truyền tải và có thể "hợp nhất" một cách có chọn lọc các chuỗi con độc lập thành một chân trời chuỗi an toàn ảo.
Những gì chúng ta đạt được
Tăng tốc thời gian khe cắm
Chúng ta có thể tăng tốc thời gian chơi bằng thiết kế này vì hai lý do.
Lý do chính là việc tổ chức lại giá rẻ. Vì các khối có thể được bỏ qua một cách có chọn lọc khỏi chuỗi chính tắc, nên về cơ bản chúng ta có các tổ chức lại rất rẻ, nghĩa là chúng ta có thể dễ dãi hơn với các khối xây dựng không thể thực hiện được vì lý do này hay lý do khác.
Lý do thứ hai là chúng ta cần ít thông tin hơn để xây dựng một Block và chúng ta có thể phân phối lượng thông tin nhỏ đó nhanh hơn nhiều trong mạng.
Giảm thời gian bao gồm giao dịch
Với thời gian khe cắm ngắn hơn, thời gian bao gồm giao dịch cũng ngắn hơn. Mặc dù điều này không quan trọng với tất cả mọi người, nhưng rõ ràng đây là một phần của trải nghiệm người dùng.
Mở rộng quy mô sản xuất Block
Vì chúng ta chỉ cần một bộ lọc rất nhỏ để tiếp cận trình xây dựng tiếp theo, chúng ta cũng có thể nghĩ đến việc song song hóa việc xây dựng Block . Một loại phân mảnh động mà không có sự phân chia không gian trạng thái được áp đặt trước. Một lần nữa, thiết kế vẫn chưa rõ ràng ở đây, nhưng tôi nghĩ chúng ta có thể đi theo hướng mà việc xây dựng Block phân tán được song song hóa và truyền qua đường ống dựa trên sự khuếch tán nhanh của BAF hoặc BMF.
Mối quan hệ với những ý tưởng khác
Người ta cũng có thể xem ý tưởng này như là nhìn vào BAL và sự nóng lên từ một góc nhìn mới. Thay vì cố gắng gửi một thay đổi trạng thái lớn nhanh chóng, chúng ta có thể cố gắng đảm bảo rằng chúng ta không có thay đổi lớn.
Cũng có những ý tưởng hướng đến việc cho phép "bỏ qua" cấp độ giao dịch trong trường hợp có xung đột. Tôi nghĩ rằng có không gian để thử kết hợp những ý tưởng như vậy, giảm thiểu, nhưng không nhất thiết phải loại bỏ các phụ thuộc giữa các khối. Chúng ta thậm chí có thể thử đưa ra một "con đường nhanh" cho các thay đổi độc lập và một "con đường chậm" (nhưng không chậm hơn hiện nay) cho các thay đổi phụ thuộc, dẫn đến một thiết kế mà khả năng chuỗi tổng thể có thể tăng lên mà không bị giới hạn bởi các giao dịch "trường hợp xấu nhất" cụ thể.
