Solana đang xem xét một bộ quy tắc giao thức mới nhằm làm cho phần mềm validator được phát triển độc lập trở nên đáng tin cậy hơn và dễ bảo trì hơn.
Dự án đề xuất, được công bố vào ngày 30 tháng 10, đến từ Brennan Watt, CEO của Anza, công ty kỹ thuật blockchain đứng sau Agave, một trong những chương trình phần mềm chính được sử dụng để vận hành mạng Solana.
Watt muốn Solana thiết lập một thông số kỹ thuật duy nhất, có thẩm quyền xác định cách blockchain của nó xử lý giao dịch, xác thực khối và đạt được sự đồng thuận, thay vì dựa vào các quy tắc rải rác trong phần mềm hiện có và các đề xuất kỹ thuật riêng biệt.
Sự thay đổi này có thể giải quyết một thách thức ngày càng gia tăng khi Solana mở rộng vượt ra ngoài phần mềm validator ban đầu để bao gồm các lựa chọn thay thế được phát triển độc lập như Firedancer, được xây dựng bởi công ty giao dịch Jump Crypto.
Các trình xác thực là các máy tính xác minh giao dịch và giúp bảo vệ blockchain. Mặc dù các nhà phát triển khác nhau có thể tạo phần mềm chạy trên những máy tính này, mọi triển khai đều phải tuân theo cùng các quy tắc cơ bản để duy trì sự đồng thuận trên toàn mạng lưới.
Sự bất đồng về các quy tắc đó có thể khiến các trình xác thực xử lý các giao dịch giống nhau một cách khác nhau, tiềm ẩn nguy cơ tạo ra những quan điểm mâu thuẫn về blockchain và đe dọa độ tin cậy của mạng lưới.
Watt cho rằng quy trình phát triển hiện tại của Solana khiến các nhóm độc lập gặp khó khăn không cần thiết trong việc xác định chính xác mạng lưới nên hoạt động như thế nào.
Theo hệ thống hiện tại, các thay đổi giao thức được đề xuất thông qua Solana Improvement Documents, còn được gọi là SIMDs. Các tài liệu này mô tả các bản nâng cấp riêng lẻ, nhưng các quy tắc vận hành đầy đủ của mạng không được tổng hợp vào một tài liệu tham chiếu chính thức.
Do đó, các nhà phát triển đôi khi phải xem xét mã validator hiện có hoặc tái tạo lại các quyết định nâng cấp trước đó để hiểu rõ những quy tắc nào đang được kích hoạt.
Watt cho biết cách tiếp cận này có thể tạo ra các mô tả lặp lại hoặc không nhất quán về hành vi hiện có, đồng thời khiến việc xác định mọi phần của giao thức bị ảnh hưởng bởi bản nâng cấp đề xuất trở nên khó khăn hơn.
Bộ quy tắc mới có thể thay đổi quy trình nâng cấp của Solana
Theo đề xuất, các nhà phát triển sẽ tiếp tục thảo luận về các bản nâng cấp tiềm năng thông qua quy trình SIMD hiện có, nhưng các thay đổi kỹ thuật chính thức sẽ được gửi dưới dạng chỉnh sửa cho một tài liệu tiêu chuẩn giao thức chung.
Mỗi sửa đổi sẽ mô tả chính xác cách nâng cấp ảnh hưởng đến các giao dịch, giao tiếp mạng, sự đồng thuận và các chức năng liên quan khác.
Các thay đổi sẽ trải qua đánh giá kỹ thuật và bất kỳ sự phê duyệt quản trị nào cần thiết trước khi trở thành một phần của thông số kỹ thuật chính thức khi được kích hoạt trên Mainnet của Solana.
Điều này sẽ cho phép các nhóm phát triển Agave, Firedancer và phần mềm validator trong tương lai làm việc dựa trên các yêu cầu được tài liệu hóa thay vì phụ thuộc vào mã của một triển khai khác làm tài liệu tham khảo chính.
Khách hàng bắt đầu từ đâu?
Việc xây dựng child-bank áp dụng chuyển tiếp ranh giới epoch-E một lần trước các giao dịch của nó.
Một bộ quy tắc chung giúp làm rõ mục tiêu. Sự tin tưởng ở trạng thái ban đầu và epoch tiếp theo là những yêu cầu riêng biệt.
Đây là bản nháp đặc tả, không phải là thay đổi giao thức đã được thông qua. Nó không xác lập tính chính xác của trạng thái khởi đầu, việc phát lại lịch sử hoặc hoạt động liên tục vào E+1. Không có lợi ích đáng tin cậy nào cho client được định lượng.
Nó cũng có thể giúp việc kiểm thử phần mềm hiệu quả hơn. Khi các người xác thực độc lập tạo ra các kết quả khác nhau, các nhà phát triển sẽ có một tiêu chuẩn chung để xem xét sự không nhất quán và xác định xem triển khai nào cần được sửa đổi.
Watt đã công bố bản nháp tiêu chuẩn bao gồm 18 lĩnh vực trong hoạt động của Solana, bao gồm xử lý giao dịch, giao tiếp mạng, đồng thuận, phí và phần thưởng cho người xác thực.
Tuy nhiên, bản nháp vẫn chỉ giới hạn trong một giai đoạn xác định của lịch sử blockchain Solana và giả định rằng các nhà phát triển bắt đầu từ một trạng thái mạng đã được tin cậy. Cần thêm công việc để bao quát các bản nâng cấp sau đó và đảm bảo rằng các triển khai vẫn tương thích theo thời gian.