Đồng sáng lập Solana: Xây dựng một cỗ máy trạng thái toàn cầu và phân tích kiến trúc tối ưu của Solana

**Từ: Anatoly Yakovenko, CEO (Đồng sáng lập &; CEO), Solana

Trình biên dịch: 1912212.eth, Tin tức tầm nhìn xa

Mục tiêu của Solana là đồng bộ hóa một cỗ máy trạng thái toàn cầu duy nhất, không được phép càng nhanh càng tốt, tuân thủ các định luật vật lý. Tôi tin rằng kiến trúc có thể đạt được điều này sẽ trông như thế này:

• Số lượng lớn các nút đầy đủ, hơn 10.000 (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ợ nhiều nút đầy đủ. Turbine đã chứng minh rằng việc sao chép nhanh sang các mạng rất lớn có thể mở rộng 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, hơn 10.000 (N > 10.000)
• Các nhà lãnh đạo đồng thời tạo ra các khối cùng một lúc, được chọn ngẫu nhiên trong phạm vi từ 4 đến 16.

Concurrency Leader cho phép mạng có nhiều địa điểm trên toàn cầu để đặt hàng các giao dịch của người dùng. Nó làm giảm khoảng cách giữa người dùng và mạng, loại bỏ nhu cầu xác minh nút đầy đủ trước khi các giao dịch được thêm vào chuỗi.

• Thời gian khối là 120 mili giây

Thời gian chặn ngắn tạo ra điểm cuối cùng nhanh, 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, giảm thời gian để sắp xếp lại các giao dịch và tăng tốc mạng tổng thể.

• Một số nút đồng thuận bỏ phiếu trong tiểu ban phê duyệt, với số lượng từ 200 đến 400, được chọn ngẫu nhiên và luân phiên cứ sau 4 đến 8 giờ mỗi kỷ nguyên.

Sự đồng thuận là điều cần thiết để chọn một fork, xảy ra do phân vùng mạng. Một mẫu gồm 200 nút trở lên sẽ đại diện thống kê cho tất cả các phân vùng chính trong mạng và phù hợp chặt chẽ với phân phối thực tế của chúng. Do đó, tất cả các phiếu bầu nút đầy đủ là không bắt buộc, 200 là đủ. Giới hạn phê duyệt cho các tiểu ban để giảm bộ nhớ và băng thông mạng cần thiết để hỗ trợ các khối 120 ms. Giảm thời gian chặn đương nhiên làm tăng số phiếu được gửi mỗi giây, gây áp lực lên các nguồn lực được phân bổ cho sự đồng thuận.

Thách thức thực sự trong khối 120ms là phát lại tất cả các giao dịch của người dùng. Vì mạng không được phép, nên cực kỳ khó đảm bảo môi trường thực thi đồng nhất với thời gian đáng tin cậy để thực thi mã người dùng tùy ý. Mặc dù có khả năng, nhưng nó chỉ có thể đạt được bằng cách giới hạn các tài nguyên tính toán có sẵn cho các giao dịch của người dùng và đảm bảo rằng mọi nút đều được phân bổ quá mức cho trường hợp xấu nhất.

Tuy nhiên, không có lý do gì để thực thi một trạng thái đầy đủ cho các nút đồng thuận bỏ phiếu cho một fork hoặc một nhà lãnh đạo xây dựng trên một fork. Để giữ cho sự chấp thuận của các nút đồng thuận và các nhà lãnh đạo đồng bộ, trạng thái chỉ cần được tính toán một lần mỗi kỳ.

Thực thi không đồ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 siêu cấu hình trong bất kỳ khối nào để xác định thời gian thực hiện trong trường hợp xấu nhất. Thực hiện không đồng bộ là một trong số rất ít trường hợp có ít sự đánh đổi. 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ổng hợp và theo lô, làm cho nó hiệu quả trong thực thi mà không mất bộ nhớ cache. Nó thậm chí có thể được thực thi trên một máy hoàn toàn khác với nút đồng thuận hoặc đơn vị chỉ huy. 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 quá trình chuyển đổi trạng thái trong thời gian thực mà không phải đợi toàn bộ mạng.

Với sự đa dạng của các ứng dụng và nhà phát triển cốt lõi, đáng để lập kế hoạch thay đổi giao thức lớn hàng năm. Nếu tôi phải chọn một, lựa chọn của tôi sẽ là thực hiện không đồng bộ.

TỔNG QUAN

Hiện tại, người xác thực nhanh chóng lặp lại tất cả các giao dịch trên mỗi khối và chỉ bỏ phiếu sau khi trạng thái hoàn chỉnh đã được tính toán cho khối. Mục tiêu của đề xuất này là tách các quyết định bỏ phiếu về fork khỏi việc tính toán chuyển đổi trạng thái đầy đủ của các khối.

Người xác thực bỏ phiếu phê duyệt chỉ cần chọn fork; họ không cần phải thực hiện bất kỳ trạng thái nào cả. Chỉ trên mỗi kỷ nguyên, họ mới cần trạng thái để tính toán phê duyệt tiếp theo.

Thủ tục bỏ phiếu đã được điều chỉnh để nó có thể được thực hiện độc lập. Các nút chỉ thực hiện các thủ tục bỏ phiếu trước khi bỏ phiếu. Vì trình xác thực không chiếm nhiều dung lượng, yêu cầu bộ nhớ phải tương đối nhỏ. Vì việc bỏ phiếu có thời gian thực hiện rất dễ đoán, nên sẽ có rất ít hoặc không có sự lo lắng trong việc thực hiện thủ tục bỏ phiếu.

Tất cả các giao dịch không có quyền biểu quyết có thể được tính toán không đồng bộ. Điều này cho phép phát lại để thực hiện tất cả các giao dịch không bỏ phiếu theo lô, tìm nạp trước và JIT tất cả các chương trình trước, hầu như loại bỏ tất cả mất bộ nhớ cache. Mục tiêu dài hạn là chỉ những máy yêu cầu tính toán trạng thái đầy đủ, độ trễ thấp, thời gian thực mới được cấu hình cho tác vụ này. Có lẽ, người dùng sẽ trả tiền cho phần cứng bổ sung.

Khi lựa chọn fork và thực thi trạng thái được tách ra, việc tăng tốc mọi thứ trở nên dễ dàng hơn:

• Thực hiện không đồng bộ
• Mỗi kỷ nguyên luân phiên một số ủy ban bỏ phiếu cố định
• Thời gian khối 200 ms

Vì phát lại giao dịch của người dùng không chặn lựa chọn fork, sự biến động không còn là vấn đề khi trừ đi thời gian khối. Điều duy nhất cần xem xét là ở 200 mili giây, tỷ lệ bỏ phiếu của trình xác thực tăng gấp đôi. Thực hiện một thay đổi khá đơn giản về cách tính hạn ngạch để phê duyệt sẽ cho phép chúng tôi ấn định kích thước của phê duyệt ở mức 200 hoặc 400, hoặc bất kỳ con số nào có vẻ phù hợp.

Nó cũng là điều tự nhiên để tách biệt hoàn toàn việc thực hiện khỏi sự đồng thuận. Sẽ nhanh hơn khi khởi động lại nút đồng thuận chỉ cần kiểm tra tài khoản chương trình bỏ phiếu trong phê duyệt kích thước cố định.

Trên thực tế, tôi tin rằng thời gian xác nhận sẽ tăng lên vì phần lớn các phê duyệt được bỏ phiếu càng nhanh càng tốt và trong khi các phiếu bầu này được lan truyền, các nút cung cấp cho người dùng kết quả thực thi trạng thái đầy đủ có thể thực hiện các giao dịch cùng một lúc. Do đó, bất kỳ sự chập chờn phát lại nào mà chúng ta thấy ngày nay sẽ xảy ra cùng lúc với việc truyền bá mạng lưới bỏ phiếu.

Bình chọn

• Tài khoản biểu quyết phải có đủ số SOL để trang trải phiếu bầu của 2 thời đại.
• Giao dịch biểu quyết phải đơn giản. Một cuộc bỏ phiếu không đơn giản chắc chắn sẽ thất bại. Trình tạo khối nên từ bỏ bỏ phiếu phức tạp.
• Cho phép rút SOL từ tài khoản bỏ phiếu, miễn là số dư không giảm xuống dưới 1 kỷ nguyên phiếu bầu.
• Để loại bỏ tất cả các lamport, chỉ thị Vote CLOSE phải yêu cầu toàn bộ kỷ nguyên trôi qua. Tài khoản bỏ phiếu được đánh dấu là ĐÓNG trong Kỷ nguyên 1, nhưng chỉ có thể ĐÓNG trong Kỷ nguyên 2. CLOSE cho phép bạn rút tất cả SOL và xóa tài khoản bỏ phiếu. Khi tài khoản được đánh dấu là ĐÓNG, tài khoản đó chỉ có thể bị xóa hoàn toàn và không thể mở lại.
• Phiếu bầu chứa VoteBankHash thay vì BankHash thông thường.

Quy định và phê duyệt của lãnh đạo

Chỉ người xác thực mới đáp ứng các tiêu chí sau:

• Số tiền đặt cược > X
• Cũng như SOL > 2 kỷ nguyên bỏ phiếu
• và không được đánh dấu là ĐÓNG

để nhập lịch trình của đơn vị chỉ huy và tính vào phê duyệt. Đối với phiên bản 2, chúng ta có thể tách LeaderSchedule khỏi Nhóm túc số và mỗi phiên bản không cần phải có cùng yêu cầu.

Tính toán VoteBankHash

Không giống như Bankhash, tính toán tất cả các giao dịch, trình 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 trình 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 theo định dạng tương tự như BankHash hiện tại.

VoteBankHash nên tích lũy VoteBankHash trước đó, 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ể định cấu hình cho tất cả các khối), trình 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 loại trừ các giao dịch đã được xem xét trong tính toán VoteBankHash.

BankHash sau đó có nguồn gốc từ sự tích lũy của (VoteBankHash, UserBankHash). 99,5% người xác thực hàng đầu gửi BankHash như một phần của cuộc bỏ phiếu của họ cứ sau 100 khoảng thời gian. Trong khi cam kết mỗi 100 khoảng thời gian, nó được tính tại mỗi khoảng thời gian. Cần lưu ý rằng có thể đáng để một tỷ lệ nhỏ các nút liên tục gửi BankHash trong tin đồn như một tín hiệu mềm mà không quan sát thấy không xác định.

Nếu ít hơn 67% người xác thực gửi các tính toán BankHash đầy đủ, các nhà lãnh đạo nên giảm 50% không gian khối có sẵn cho các giao dịch của người dùng và tài khoản có thể ghi. Biện pháp này là để bảo vệ chuỗi khỏi sự 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 BankHashes trước đó.

Đến gặp lãnh đạo ngân hàng

Trong quá trình tạo khối, có khả năng đơn vị chỉ huy sẽ không thể có được trạng thái được sử dụng để tạo khối và không lý tưởng để thực hiện tất cả các giao dịch trong giai đoạn tạo khối.

• Các nhà lãnh đạo duy trì một bộ nhớ cache của số dư tài khoản trả tiền.
• Nếu tài khoản trả phí được sử dụng làm nguồn chuyển hệ thống hoặc dưới dạng tài khoản có thể ghi được chuyển cùng với chương trình hệ thống sang chương trình khác, thì số dư tài khoản trả phí được đặt thành 0.
• Các khối được đóng gói theo đơn vị tính toán đã khai báo (CU) theo thứ tự ưu tiên phí địa phương cho đến khi các khối được lấp đầy.
• Phí được khấu trừ từ bộ nhớ đệm số dư tài khoản trả phí.
• Bộ nhớ đệm số dư tài khoản trả phí được bổ sung bằng tính toán BankHash.

Mạng phải chịu chi phí tương đối ít cho các lỗi spam giao dịch, chỉ bao gồm các byte được lưu trữ trong kho lưu trữ và băng thông cần thiết để truyền bá các giao dịch trong khối.

Do các trình xác thực đã tìm cách tối đa hóa thu nhập của họ, họ có nhiều ưu đãi để duy trì bộ nhớ cache chính xác của các tài khoản trả phí. Ngoài ra, nếu không có hình phạt tại chỗ, bất kỳ ai trong bất kỳ mạng nào cũng có thể dễ dàng phục vụ bộ nhớ cache về lâu dài. Trong trường hợp máy chủ bị hỏng, nhà điều hành nhà điều hành nhà lãnh đạo không có ngân hàng sẽ 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 của người xác thực để tối đa hóa thu nhập, họ sẽ cố gắng duy trì bộ nhớ cache chính xác của các tài khoản trả phí. Trong trường hợp không có cơ chế phạt, bộ đệm này có thể được phục vụ bởi bất kỳ nút nào trong mạng trong một thời gian dài. Ngoài ra, nếu một máy chủ bị lỗi, một nhà điều hành không có lãnh đạo ngân hàng sẽ có thể dễ dàng chuyển đổi hoặc lấy mẫu từ nhiều nguồn.

Đánh đổi

Sự đánh đổi chính là thiếu chữ ký xác nhận trên nút đầy đủ phục vụ trạng thái người dùng để xác nhận rằng trạng thái phân phối của nó hoàn toàn giống với phần còn lại đã được phê duyệt. Lời giải thích có thẩm quyền duy nhất của nhà nướ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 làm thay đổi kết quả. Vì vậy, một khi fork được hoàn tất, chỉ còn lại trạng thái chính xác để tính toán, miễn là việc triển khai thời gian chạy không có lỗi.

Các nút được thiết kế để cung cấp trạng thái một cách đáng tin cậy nên chạy nhiều máy và máy khách và nếu có sự khác biệt trong thực thi trạng thái, chúng sẽ ngừng hoạt động. Về cơ bản, đây là những gì các nhà khai thác nên làm ngày hôm nay, bởi vì chỉ dựa vào phần còn lại của mạng giới thiệu hầu hết các giả định về tính toàn vẹn.

Người dùng cũng có thể ký các giao dịch khẳng định BankHash hoặc kích hoạt hủy bỏ. Phần còn lại của mạng sẽ chỉ thực hiện các giao dịch này nếu BankHash chính xác được tính toán hoàn toàn giống với BankHash do nhà cung cấp RPC cung cấp cho người dùng.

Lộ trình nút đồng thuận không trạng thái dài hạn

Các mạng có phê duyệt kích thước cố định chỉ yêu cầu một lượng trạng thái rất nhỏ để bắt đầu. Bản thân sự chấp thuận và trọng lượng cam kết của nó, cũng như 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 ảnh chụp nhanh nhỏ có thể được phân phối nhanh chóng và khởi tạo nhanh chóng khi khởi động lại.

Nếu phê duyệt không nhất quán với nút đầy đủ, nút đầy đủ đang theo dõi cả phê duyệt và trạng thái sẽ ngừng chạy. Điều này có nghĩa là nếu có sự bất đồng giữa phê duyệt và trạng thái, sàn giao dịch, kênh fiat, RPC, cầu, v.v., tất cả sẽ ngừng hoạt động. Điều này chỉ đòi hỏi một tỷ lệ rất nhỏ các nút đồng thuận không trạng thái bị lỗi.

Các nhà lãnh đạo không có ngân hàng có thể dựa vào một mẫu gồm nhiều nút đầy đủ để cung cấp bộ nhớ cache về số dư ban đầu của tài khoản trả phí. Ngay cả khi nó có thiếu sót, kết quả sẽ là spam trong khối chứ không phải là thất bại đồng thuận. Các nhà khai thác sẽ có thể theo dõi sức khỏe của các nhà lãnh đạo của họ và tỷ lệ phần trăm thư rác mà họ đưa vào các khối của họ và phản ứng nhanh chóng với các thất bại.