Cofounder của Solana: Phân tích kiến trúc tối thượng của Solana
Tuyển chọn TechFlowTuyển chọn TechFlow
Cofounder của Solana: Phân tích kiến trúc tối thượng của Solana
Tất cả các giao dịch không phải bỏ phiếu đều có thể được tính toán bất đồng bộ.
Chuyên sâu báo cáo Web3Tác giả: Anatoly Yakovenko, Giám đốc điều hành Solana (Đồng sáng lập và CEO)
Biên dịch: 1912212.eth, Foresight News
Mục tiêu của Solana là đồng bộ hóa một máy trạng thái toàn cầu duy nhất, không cần sự cho phép, nhanh nhất có thể trong giới hạn của các định luật vật lý. Tôi tin rằng kiến trúc có thể đạt được mục tiêu này sẽ như sau:
-
Số lượng lớn các nút đầy đủ, hơn 10.000 nút (N > 10.000)
Để mạng hoạt động như một máy trạng thái toàn cầu, nó cần hỗ trợ rất nhiều nút đầy đủ. Turbine đã chứng minh rằng việc sao chép nhanh đến một mạng cực lớn là khả thi trên phần cứng và mạng hiện đại.
-
Số lượng lớn các nhà lãnh đạo tạo khối, vượt quá 10.000 (N > 10.000)
-
Các nhà lãnh đạo hoạt động song song cùng lúc tạo ra các khối, được chọn ngẫu nhiên trong khoảng từ 4 đến 16.
Việc có nhiều nhà lãnh đạo song song cho phép mạng có nhiều vị trí trên toàn cầu để sắp xếp giao dịch người dùng. Điều này giúp giảm khoảng cách giữa người dùng và mạng, loại bỏ nhu cầu phải xác thực toàn bộ nút trước khi giao dịch được thêm vào chuỗi.
-
Thời gian khối là 120 mili giây
Thời gian khối ngắn tạo ra các điểm hoàn tất nhanh chóng, tăng cường khả năng chống kiểm duyệt, cải thiện trải nghiệm người dùng, thu hẹp cửa sổ thay đổi thứ tự giao dịch và tăng tốc độ tổng thể của mạng.
-
Một số nút bỏ phiếu đạt được thỏa thuận trong tiểu ban phê chuẩn, với số lượng từ 200 đến 400, nhà lãnh đạo được chọn ngẫu nhiên và luân phiên mỗi epoch trong khoảng 4 đến 8 giờ.
Thỏa thuận đồng thuận là thiết yếu để lựa chọn phân nhánh, xảy ra do phân vùng mạng. Một mẫu gồm 200 hoặc nhiều nút hơn sẽ về mặt thống kê đại diện cho tất cả các phân vùng chính trong mạng và sát với phân bố thực tế của chúng. Do đó, không cần tất cả các nút đầy đủ đều bỏ phiếu — 200 là đủ. Việc giới hạn phê chuẩn thành tiểu ban làm giảm bộ nhớ và băng thông mạng cần thiết để hỗ trợ thời gian khối 120 mili giây. Việc rút ngắn thời gian khối tự nhiên làm tăng số lượng phiếu bầu gửi đi mỗi giây, gây áp lực lên tài nguyên dành cho đồng thuận.
Thách thức thực sự trong khối 120 mili giây là phát lại tất cả các giao dịch người dùng. Vì mạng không yêu cầu cấp phép, việc đảm bảo một môi trường thực thi đồng nhất để thực thi mã người dùng bất kỳ với thời gian đáng tin cậy là cực kỳ khó khăn. Mặc dù điều này là khả thi, nhưng chỉ có thể thực hiện bằng cách giới hạn tài nguyên tính toán mà giao dịch người dùng có thể sử dụng và đảm bảo mọi nút đều được cấu hình dư thừa cho trường hợp xấu nhất.
Tuy nhiên, đối với các nút đồng thuận bỏ phiếu ủng hộ phân nhánh hoặc các nhà lãnh đạo xây dựng trên phân nhánh, không có lý do gì để thực thi toàn bộ trạng thái. Để giữ cho các nút đồng thuận và nhà lãnh đạo trong tiểu ban phê chuẩn đồng bộ, trạng thái chỉ cần được tính toán một lần trong mỗi giai đoạn.
Thực thi bất đồng bộ
Động lực
Thực thi đồng bộ yêu cầu tất cả các nút bỏ phiếu và tạo khối phải được cấu hình dư thừa ở mức cao nhất để xác định thời gian thực thi trong trường hợp xấu nhất. Thực thi bất đồng bộ là một trong những trường hợp hiếm hoi gần như không có sự đánh đổi nào. Các nút đồng thuận có thể thực hiện ít công việc hơn trước khi bỏ phiếu. Công việc có thể được tập hợp và xử lý theo lô, giúp việc thực thi hiệu quả mà không bị mất bộ đệm. Nó thậm chí có thể được thực hiện trên các máy hoàn toàn khác biệt so với nút đồng thuận hay nhà lãnh đạo. Người dùng muốn thực thi đồng bộ có thể phân bổ đủ tài nguyên phần cứng để thực hiện từng chuyển đổi trạng thái theo thời gian thực, mà không cần chờ đợi toàn bộ mạng.
Xét đến sự đa dạng của các ứng dụng và nhà phát triển cốt lõi, nên lên kế hoạch thay đổi giao thức chính hàng năm một lần. Nếu phải chọn một thay đổi, tôi sẽ chọn thực thi bất đồng bộ.
Tổng quan
Hiện tại, các bộ xác thực nhanh chóng lặp lại tất cả các giao dịch trong mỗi khối và chỉ bỏ phiếu sau khi đã tính toán xong trạng thái đầy đủ của khối. Mục tiêu của đề xuất này là tách quyết định bỏ phiếu cho phân nhánh khỏi việc tính toán chuyển đổi trạng thái đầy đủ của khối.
Các bộ xác thực bỏ phiếu trong tiểu ban phê chuẩn chỉ cần chọn phân nhánh; họ hoàn toàn không cần thực thi bất kỳ trạng thái nào. Chỉ mỗi epoch, họ mới cần trạng thái để tính toán phê chuẩn tiếp theo.
Chương trình bỏ phiếu được điều chỉnh để có thể thực thi độc lập. Nút chỉ thực thi chương trình bỏ phiếu trước khi bỏ phiếu. Vì các giao dịch bỏ phiếu chiếm rất ít dung lượng, yêu cầu bộ nhớ nên tương đối nhỏ. Do thời gian thực thi bỏ phiếu rất dễ dự đoán, việc thực thi chương trình bỏ phiếu gần như không bị rung (jitter).
Tất cả các giao dịch không phải bỏ phiếu có thể được tính toán bất đồng bộ. Điều này cho phép phát lại hàng loạt tất cả các giao dịch không phải bỏ phiếu, tải trước và biên dịch JIT cho tất cả các chương trình sớm, gần như loại bỏ mọi mất mát bộ đệm. Mục tiêu dài hạn là chỉ những máy cần tính toán trạng thái đầy đủ với độ trễ thấp theo thời gian thực mới được cấu hình cho nhiệm vụ này. Dự kiến, người dùng sẽ trả phí cho phần cứng bổ sung.
Một khi đã tách rời việc lựa chọn phân nhánh và thực thi trạng thái, việc đẩy nhanh tiến độ sẽ trở nên dễ dàng hơn:
-
Thực thi bất đồng bộ
-
Luân chuyển tiểu ban bỏ phiếu với số lượng cố định mỗi epoch
-
Thời gian khối 200 mili giây
Vì việc phát lại giao dịch người dùng không còn chặn việc lựa chọn phân nhánh, biến động không còn là vấn đề khi giảm thời gian khối. Điều duy nhất cần cân nhắc là tại 200 mili giây, tốc độ bỏ phiếu của bộ xác thực tăng gấp đôi. Một thay đổi khá trực tiếp về cách tính toán hạn ngạch phê chuẩn sẽ cho phép chúng ta cố định kích thước phê chuẩn ở mức 200 hoặc 400, hoặc bất kỳ con số nào phù hợp.
Việc tách biệt hoàn toàn thực thi khỏi đồng thuận cũng là điều tự nhiên. Việc khởi động lại sẽ nhanh hơn vì chỉ cần kiểm tra các tài khoản chương trình bỏ phiếu của các nút đồng thuận trong phê chuẩn kích thước cố định.
Trên thực tế, tôi tin rằng thời gian xác nhận sẽ được cải thiện, bởi vì phần lớn phê chuẩn sẽ bỏ phiếu nhanh nhất có thể, trong khi các nút cung cấp kết quả thực thi trạng thái đầy đủ cho người dùng có thể thực hiện giao dịch đồng thời khi các lá phiếu đang lan truyền. Do đó, bất kỳ hiện tượng rung phát lại nào mà chúng ta thấy ngày nay nên xảy ra đồng thời với quá trình lan truyền phiếu bầu.
Bỏ phiếu
-
Tài khoản bỏ phiếu phải sở hữu lượng SOL đủ để bao phủ 2 epoch bỏ phiếu.
-
Giao dịch bỏ phiếu phải đơn giản. Giao dịch bỏ phiếu không đơn giản chắc chắn sẽ thực thi thất bại. Nhà tạo khối nên từ chối các giao dịch bỏ phiếu phức tạp.
-
Cho phép rút SOL khỏi tài khoản bỏ phiếu, miễn là số dư không giảm xuống dưới mức cần thiết cho 1 epoch bỏ phiếu.
-
Để xóa sạch tất cả lamport, lệnh Vote CLOSE yêu cầu một epoch đầy đủ phải trôi qua. Tài khoản bỏ phiếu được đánh dấu là CLOSE ở epoch 1, nhưng chỉ có thể thực hiện CLOSE ở epoch 2. CLOSE cho phép rút toàn bộ SOL và xóa tài khoản bỏ phiếu. Một khi tài khoản đã được đánh dấu là CLOSE, nó chỉ có thể bị xóa hoàn toàn và không thể mở lại.
-
Phiếu bầu chứa một VoteBankHash thay vì BankHash thông thường.
Kiểm soát nhà lãnh đạo và phê chuẩn
Chỉ những bộ xác thực đáp ứng các điều kiện sau đây:
-
Số lượng stake > X
-
Và SOL > 2 epoch bỏ phiếu
-
Và không bị đánh dấu là CLOSE
mới được tham gia lịch trình nhà lãnh đạo và tính vào phê chuẩn. Đối với phiên bản 2, chúng ta có thể tách LeaderSchedule khỏi Quorum, các yêu cầu riêng của chúng không nhất thiết phải giống nhau.
Tính toán VoteBankHash
Khác với việc tính toán Bankhash cho tất cả các giao dịch, các bộ xác thực chỉ tính toán VoteBankHash cho các giao dịch bỏ phiếu đơn giản liên quan đến các bộ xác thực trong LeaderScheduler. Tất cả các giao dịch khác đều bị bỏ qua. Sau khi phát lại tất cả các phiếu bầu, VoteBankHash được tính toán theo định dạng giống như BankHash hiện tại.
VoteBankHash nên tích lũy VoteBankHash trước đó, chứ không phải BankHash đầy đủ.
Tính toán BankHash
Đối với tất cả các khối được xác nhận lạc quan (có thể cấu hình cho tất cả các khối), các bộ xác thực bắt đầu tính toán UserBankHash, bao gồm tất cả các chuyển đổi trạng thái, nhưng không bao gồm các giao dịch đã được xét trong tính toán VoteBankHash.
Sau đó, BankHash được suy ra từ sự tích lũy của (VoteBankHash, UserBankHash). 99,5% số bộ xác thực hàng đầu sẽ gửi BankHash mỗi 100 khe thời gian như một phần trong phiếu bầu của họ. Mặc dù được gửi mỗi 100 khe thời gian, nhưng nó được tính toán ở mỗi khe thời gian. Đáng chú ý là, việc một tỷ lệ nhỏ các nút luôn gửi BankHash qua gossip như một tín hiệu mềm cho thấy không có hiện tượng phi xác định nào có thể quan sát được là điều đáng cân nhắc.
Nếu ít hơn 67% bộ xác thực gửi tính toán BankHash đầy đủ, nhà lãnh đạo nên giảm 50% không gian khối dành cho các giao dịch người dùng và tài khoản có thể ghi. Biện pháp này nhằm bảo vệ chuỗi khỏi các hành vi lạm dụng có thể làm tăng quá mức thời gian phát lại.
BankHash nên tích lũy BankHash trước đó.
Nhà lãnh đạo không cần ngân hàng
Trong quá trình tạo khối, nhà lãnh đạo có thể không truy cập được trạng thái dùng để tạo khối, và việc thực thi tất cả các giao dịch trong quá trình tạo khối là không lý tưởng.
-
Nhà lãnh đạo duy trì bộ nhớ đệm số dư tài khoản thanh toán.
-
Nếu một tài khoản thanh toán được dùng làm nguồn trong chuyển tiền hệ thống, hoặc được truyền như một tài khoản ghi được cùng với chương trình hệ thống tới một chương trình khác, thì số dư tài khoản thanh toán đó được đặt thành 0.
-
Sắp xếp gói giao dịch theo thứ tự ưu tiên phí cục bộ dựa trên đơn vị tính toán (CUs) được khai báo, cho đến khi khối đầy.
-
Trừ phí từ bộ nhớ đệm số dư tài khoản thanh toán.
-
Bộ nhớ đệm số dư tài khoản thanh toán được bổ sung bởi quá trình tính toán BankHash.
Chi phí mà mạng phải chịu do thất bại vì rác giao dịch là tương đối nhỏ, chỉ bao gồm byte lưu trữ trong kho lưu trữ và băng thông cần thiết để lan truyền các giao dịch trong khối.
Vì các bộ xác thực đã tìm cách tối đa hóa lợi nhuận của mình, họ có động lực mạnh mẽ để duy trì một bộ nhớ đệm tài khoản thanh toán chính xác. Hơn nữa, nếu không có cơ chế trừng phạt, về lâu dài, bất kỳ ai trong mạng cũng có thể dễ dàng cung cấp dịch vụ cho bộ nhớ đệm này. Trong trường hợp máy chủ hỏng, các nhà điều hành nhà lãnh đạo không cần ngân hàng nên có thể dễ dàng chuyển đổi hoặc lấy mẫu từ nhiều nguồn.
Điều này có nghĩa là do động lực tối đa hóa lợi nhuận, các bộ xác thực sẽ nỗ lực duy trì bộ nhớ đệm tài khoản thanh toán chính xác. Trong trường hợp không có cơ chế trừng phạt, bộ nhớ đệm này có thể được phục vụ lâu dài bởi bất kỳ nút nào trong mạng. Ngoài ra, nếu máy chủ gặp sự cố, các nhà vận hành nhà lãnh đạo không cần ngân hàng nên có thể dễ dàng chuyển đổi hoặc lấy mẫu từ nhiều nguồn.
Sự đánh đổi
Sự đánh đổi chính nằm ở chỗ các nút đầy đủ cung cấp trạng thái cho người dùng thiếu chữ ký xác nhận, để đảm bảo trạng thái họ cung cấp hoàn toàn khớp với phần còn lại của phê chuẩn. Giải thích trạng thái duy nhất mang tính quyền lực nên giữ nguyên, ngay cả khi mỗi giao dịch được phát lại tuần tự trong sổ cái. Bất kỳ tối ưu hóa hiệu suất nào cũng không được thay đổi kết quả. Do đó, một khi phân nhánh đã được xác định cuối cùng, chỉ còn lại một trạng thái đúng duy nhất có thể tính toán, miễn là triển khai runtime không có lỗi.
Các nút nhằm cung cấp trạng thái đáng tin cậy nên chạy nhiều máy và nhiều khách hàng, và nếu phát hiện sự khác biệt trong thực thi trạng thái, chúng nên ngừng hoạt động. Về cơ bản, đây là điều mà các nhà vận hành nên làm ngày nay, vì việc chỉ phụ thuộc vào phần còn lại của mạng đưa ra giả định về đa số trung thực.
Người dùng cũng có thể ký các giao dịch tuyên bố BankHash hoặc kích hoạt dừng. Chỉ khi BankHash chính xác được tính toán trùng khớp hoàn toàn với BankHash do nhà cung cấp RPC cung cấp cho người dùng, phần còn lại của mạng mới thực thi các giao dịch này.
Lộ trình dài hạn cho các nút đồng thuận vô trạng thái
Mạng với phê chuẩn kích thước cố định chỉ cần một lượng trạng thái rất nhỏ để khởi động. Bản thân phê chuẩn, trọng số stake của nó và tất cả số dư tài khoản bỏ phiếu. Đây là một lượng bộ nhớ rất nhỏ và một tệp snapshot nhỏ có thể được phân phối nhanh chóng và khởi tạo nhanh khi khởi động lại.
Nếu phê chuẩn không nhất quán với các nút đầy đủ, các nút đầy đủ đang theo dõi đồng thời phê chuẩn và trạng thái sẽ ngừng hoạt động. Điều này có nghĩa là nếu phê chuẩn và trạng thái lệch nhau, các sàn giao dịch, kênh fiat, RPC, cầu nối,... sẽ đều ngừng hoạt động. Điều này chỉ cần một tỷ lệ cực nhỏ các nút đồng thuận vô trạng thái bị lỗi.
Nhà lãnh đạo không cần ngân hàng có thể dựa vào mẫu từ nhiều nút đầy đủ để cung cấp bộ nhớ đệm số dư ban đầu cho tài khoản thanh toán. Ngay cả khi có lỗi, kết quả cũng chỉ là rác trong khối chứ không phải thất bại đồng thuận. Các nhà vận hành nên có thể giám sát tình trạng sức khỏe của nhà lãnh đạo và tỷ lệ rác họ đưa vào khối, để phản ứng nhanh với sự cố.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@anatolyakovenko
