Tác giả: toly, đồng sáng lập Solana
Biên soạn bởi: Felix, PANews
Khoảng 1 triệu tài khoản mới được thêm vào Solana mỗi ngày và tổng trạng thái hiện đã vượt quá 500 triệu, với kích thước ảnh chụp nhanh khoảng 70GB. Khi phần cứng được cải thiện, bản thân những con số này hoàn toàn có thể quản lý được, nhưng mục tiêu của thời gian chạy SVM là cung cấp quyền truy cập rẻ nhất vào phần cứng và để đạt được điều này, trạng thái và bộ nhớ phải được quản lý trong giới hạn phần cứng hiện tại.
băng thông PCI
Kể từ năm 2024, băng thông PCI mới nhất có thể đạt thông lượng từ 0,5 Tbs đến 1 Tb. Hoặc 64GB đến 128GB mỗi giây. Mặc dù nghe có vẻ lớn nhưng nếu tx đọc/ghi 128MB thì băng thông PCI 128GBps sẽ giới hạn TPS của chuỗi ở khoảng 1000. Trên thực tế, hầu hết các tx đều truy cập vào bộ nhớ đã được tải và lưu vào bộ nhớ đệm gần đây trong RAM. Một thiết kế lý tưởng sẽ cho phép tải 1000 tx với 128 MB trạng thái mới, cộng với 10k tx trở lên để đọc và ghi trạng thái được lưu trong bộ nhớ đệm hiện có.
Chỉ mục tài khoản
Tạo một tài khoản mới yêu cầu bằng chứng rằng tài khoản đó hiện không tồn tại. Việc này thường được thực hiện tự động trên mỗi trình xác thực vì mỗi trình xác thực có một chỉ mục đầy đủ về tất cả các tài khoản hiện đang hoạt động. Ngay cả khi dữ liệu tài khoản không được lưu trữ cục bộ, chỉ là hàm băm của dữ liệu, 500 triệu tài khoản sẽ là 32 byte khóa + 32 byte hàm băm dữ liệu hoặc 64 byte cho mỗi mục, tức là 32 GB. Điều này là đủ để đảm bảo tách RAM và đĩa.
kích thước ảnh chụp nhanh
Ở một số kích thước ảnh chụp nhanh nhất định, thời gian cần thiết để khởi động nguội một hệ thống mới đủ để kéo dài thời gian khởi động lại trong trường hợp xấu nhất nếu xảy ra lỗi phần cứng trên một phần mạng. Mọi thứ thay đổi hàng ngày khi băng thông và phần cứng được cải thiện và Solana không đạt đến giới hạn đó, nhưng giới hạn đó tồn tại ở bất kỳ thời điểm nào.
Tổng quan
Bộ nhớ và đĩa có những đặc điểm và hạn chế về hiệu suất khác nhau. Nếu SVM không phân biệt thì các giao dịch và giới hạn phải được định giá trong trường hợp xấu nhất, do đó hạn chế hiệu suất. Tối thiểu, tất cả các khóa tài khoản phải có sẵn trong quá trình thực hiện giao dịch và tổng số tài khoản sẽ ảnh hưởng đến việc sử dụng băng thông PCIi của RAM và ổ đĩa. Ảnh chụp nhanh không thể được phóng to tùy ý. Giải pháp lý tưởng là:
Cho phép đóng gói nhiều tx hơn không yêu cầu tài nguyên PCI thành từng khối
Quản lý tổng kích thước chỉ mục và kích thước ảnh chụp nhanh
Lạnh, Bơ, LSR. Một cái tên xấu thường là dấu hiệu của một thiết kế phần mềm tốt. Các kỹ sư tại Anza và Firedancer đã đưa ra giải pháp sau.
Se se lạnh
Bộ nhớ đệm thời gian chạy của tài khoản được tất cả các phiên bản quản lý một cách xác định. Ở mức cao, đây là bộ đệm LRU của trạng thái truy cập. Việc triển khai này giúp dễ dàng kiểm tra các tài khoản trong quá trình xây dựng và lập lịch khối mà không cần phải khóa hoặc lặp lại bộ đệm LRU. Bộ đệm được thực hiện bằng cơ chế truy cập rất đơn giản.
Tổng số byte đã tải được theo dõi dưới dạng Bank::loaded_bytes:u64
Mỗi tài khoản được gắn thẻ với tổng tài khoản đang chạy hiện tại::load_counter:u64 khi sử dụng
Khi tải tài khoản, nếu Bank::loaded_bytes - Account::load_counter > CACHE_SIZE, tài khoản được coi là tài khoản lạnh và kích thước của nó được tính dựa trên LOAD_LIMIT mỗi khối
Tài khoản mới có load_counter bằng 0, vì vậy tất cả tài khoản mới đều là tài khoản nguội
Bộ lập lịch của người lãnh đạo xử lý LOAD_LIMIT dưới dạng hình mờ, tương tự như giới hạn CU khóa ghi.
Điều thú vị về thiết kế này là nó phù hợp một cách tự nhiên với các bộ lập lịch hiện tại. Người dùng chỉ cần lo lắng về phí ưu tiên của họ. Bộ lập lịch phải giải quyết việc đưa vào ba lô tất cả tx dưới LOAD_LIMIT và giới hạn khóa ghi tài khoản. Tx có mức ưu tiên cao nhất có thể được tải trước và sử dụng LOAD_LIMIT. Khi đạt đến giới hạn này, tất cả các tx khác vẫn có thể được đưa vào một khối. Do đó, trình xác thực có thể tối đa hóa việc giảm thiểu vị trí bộ đệm của txs.
Trái bơ
Avacado bao gồm hai phần, nén trạng thái và nén chỉ mục. Trước tiên, hãy thay thế dữ liệu tài khoản bằng hàm băm, sau đó di chuyển chỉ mục tài khoản sang Trie nhị phân/patricia Trie. Các tài khoản mới phải cung cấp bằng chứng rằng chúng không nằm trong "trie".
nén trạng thái
Thiết kế thô như sau:
Trong quá trình phân bổ, mỗi tài khoản bị ràng buộc với X lamport trên mỗi byte.
Nếu như
Nén là một quá trình gồm nhiều bước chạy trong một kỷ nguyên
Dữ liệu tài khoản được thay thế bằng băm (dữ liệu)
Khóa tài khoản vẫn ở trạng thái
Giao dịch tham chiếu tài khoản nén không thành công
Giải nén yêu cầu tải lên dữ liệu tương tự như trình tải
Chi phí giải nén phải bằng chi phí cấp phát tài khoản mới
Ước tính có khoảng 75% tài khoản chưa được truy cập trong hơn 6 tháng và có thể sẽ không bao giờ được truy cập. Nén chúng giúp tiết kiệm 50% kích thước ảnh chụp nhanh.
Nén chỉ mục
Đây là một vấn đề khó giải quyết hơn. Chỉ với tính năng nén trạng thái, người xác thực vẫn sở hữu tất cả các tài khoản hợp lệ có thể có trong hệ thống. Tạo một tài khoản mới yêu cầu kiểm tra cơ sở dữ liệu này. Chi phí cho người xác thực để lưu trữ cơ sở dữ liệu này cao nhưng chi phí để người dùng tạo tài khoản mới lại thấp. Đảm bảo rằng khóa riêng mới không xung đột với các tài khoản hiện có.
Khai thác Trie nhị phân
Trie nhị phân được theo dõi như một phần của ảnh chụp nhanh
Người xác thực muốn kiếm thêm sol có thể tạo giao dịch loại bỏ các cặp tài khoản-kv đã nén khỏi trạng thái và thêm chúng vào Bộ ba nhị phân
Người dùng có thể thực hiện ngược lại mà không được phép làm như vậy bằng cách xóa kv khỏi Trie trong quá trình giải nén (điều này có thể yêu cầu các thao tác nguyên tử khi giải nén để giúp dễ dàng hơn khi cung cấp các tài khoản nén ở chế độ nền).
Đối với trình xác thực, kích thước của gốc Trie không đổi cho dù nó chứa bao nhiêu cặp kv
Sử dụng zkp, có thể nén khoảng 30 tài khoản trên mỗi tx
Giả sử chỉ có một khối trên mỗi khối, sẽ mất khoảng 80 ngày để thu gọn 500 triệu tài khoản
Điều quan trọng của quy trình này là những người xác thực thực hiện hành động này sẽ được khen thưởng, nhưng không phải tất cả những người xác thực đều bắt buộc phải thực hiện hành động này. Nếu tất cả các trình xác thực phải thực hiện việc này thì tất cả các trình xác nhận sẽ phải duy trì nội dung của Trie nhị phân hiện tại, có nghĩa là toàn bộ trạng thái sẽ phải là một phần của ảnh chụp nhanh. Trình xác thực muốn duy trì toàn bộ trạng thái phải gửi giao dịch nén N tài khoản trong chỉ mục thành một bản thử nghiệm.
Bằng chứng tài khoản mới
Để tạo tài khoản mới, người dùng phải chứng minh tài khoản đó không tồn tại trên Trie. Trình xác thực duy trì toàn bộ trạng thái có thể tạo bằng chứng cho thấy tài khoản không có trong Trie. Điều này đặt gánh nặng lên người dùng, những người phải luôn kết nối với một nhà cung cấp lớn của bang để tạo ra những bằng chứng này.
Ngoài ra, người dùng có thể chứng minh rằng tài khoản của họ đã được tạo bằng hàm băm PoH gần đây. Cách đơn giản nhất để hỗ trợ việc này là:
Tạo PKI mới
Địa chỉ tài khoản là hàm băm (băm PoH gần nhất, PKI::public_key)
Cho rằng các tài khoản trong Trie trước tiên phải trải qua quá trình nén trạng thái, điều này đòi hỏi một kỷ nguyên đầy đủ. Bất kỳ tài khoản nào trong Trie đều không thể sử dụng hàm băm PoH gần đây để tạo địa chỉ.
Các phương pháp khác có thể được hỗ trợ là bản thân việc tạo PKI có thể cung cấp bằng chứng cho thấy khóa riêng được tạo bằng hàm băm (bí mật ẩn của người dùng, hàm băm PoH gần đây).
LSR
Tiền thuê đơn giản nhẹ, còn được gọi là Tiền thuê ít ngu ngốc hơn. Bạn định giá chi phí phân bổ tài khoản mới như thế nào và làm cách nào để đảm bảo rằng các tài khoản cũ bị bỏ rơi cuối cùng sẽ được nén và giảm tải tổng thể cho hệ thống cũng như mức giá cho người dùng mới?
Hệ thống thuê (Rent) cần được khôi phục. Tiền thuê có nghĩa là các tài khoản ở trạng thái hiện tại sẽ bị tính phí X USD/byte/ngày, giống như các tài khoản trên AWS trả phí lưu trữ.
Đường cong ràng buộc lãi suất thuê
RentRate = K*(state_size)^N
Bất kể kích thước trạng thái hiện tại là bao nhiêu, tốc độ sẽ ở mức thấp nếu nó nhỏ hoặc rất cao nếu gần với giới hạn ảnh chụp nhanh.
Phân bổ giá trái phiếu tối thiểu
Tài khoản phải tồn tại ít nhất một kỷ nguyên. Cần phải có sự chuyển nhượng để đưa tài khoản vào trạng thái Nóng. Tài khoản nóng nên tồn tại trong quá trình lưu vào bộ nhớ đệm.
Trái phiếu tài khoản mới = Slots Epoch * RentRate * Tài khoản::size
Các tài khoản mới phải có ít nhất số lamport này trong số dư trước khi có thể tạo chúng.
Đốt cháy tài khoản nóng
lruturnverrate = Thời gian trung bình mỗi tài khoản sử dụng trong bộ đệm LRU, tối đa 1 epoch. Giá trị này có thể là một hằng số hoặc có thể được tính toán ngoài chuỗi và được báo cáo cho SVM dưới dạng hằng số trọng số cổ phần trung bình.
nén
Khi (khe hiện tại - tài khoản::creation_slot) * RentRate * tài khoản::size > tài khoản::lamports, hãy nén tài khoản và ghi tất cả các lamport.
Giải pháp trên sẽ làm cho State trở nên rẻ hơn, vì theo thời gian, các tài khoản không được sử dụng cuối cùng sẽ đạt đến mức lamborts 0 và sẽ bị nén. Vì vậy, chi phí dữ liệu sẽ giảm và thậm chí chi phí lập chỉ mục cũng sẽ giảm, điều này sẽ làm giảm kích thước của trạng thái hiện tại. Giảm kích thước của trạng thái sẽ giảm chi phí phân bổ siêu bậc hai.
