• Ngày 30 tháng 10, CEO Anza Brennan Watt đề xuất chuyển quy trình rà soát SIMD của Solana sang một bản đặc tả giao thức chung.

• Solana Foundation xác nhận cuộc thảo luận về việc thống nhất bản đặc tả trong thông báo phát triển ngày 5 tháng 11.

• Bản dự thảo đặc tả giao thức của Watt gồm 18 chương và dẫn chiếu đến epoch 1072 trên mainnet.

Một bộ quy tắc, ba ứng dụng khách

Một mạng lưới có các quy tắc được thực thi bởi ba ứng dụng khách trình xác thực được xây dựng độc lập nên xác định những quy tắc đó là gì như thế nào? Câu hỏi này giờ đây được đặt ra trước các nhà phát triển Solana (SOL), sau khi CEO Anza Brennan Watt đề xuất chuyển việc rà soát các thay đổi giao thức sang một bản đặc tả chung duy nhất. Ngày 30 tháng 10, Watt đăng đề xuất có tiêu đề “Chuyển sang đặc tả giao thức” lên diễn đàn thảo luận về tài liệu cải tiến Solana (SIMD). Đến ngày 5 tháng 11, Solana Foundation, tổ chức điều phối hoạt động phát triển Solana nói chung, đã đăng thông báo phát triển xác nhận rằng cuộc thảo luận về việc thống nhất bản đặc tả và sửa đổi quy trình rà soát chính thức bắt đầu. Cho đến nay, các tài liệu SIMD vừa là phương tiện rà soát những thay đổi về quy tắc, vừa trên thực tế là hồ sơ ghi lại cách thức hoạt động của giao thức mạng lưới. Cuộc tranh luận mở ra khi giá Solana (SOL) giảm 6,8% trong 24 giờ qua. Đây là diễn biến thị trường kéo dài đà giảm xuống dưới 100 USD, chứ không phải phản ứng trước chính đề xuất này; các ngưỡng mà nhà giao dịch đang theo dõi hiện được đề cập trong phân tích kỹ thuật Solana. Watt cho rằng quy trình hiện tại giúp tích lũy các đề xuất hiệu quả, nhưng lại khiến những quy tắc đang có hiệu lực bị phân tán trong mã của các ứng dụng khách trình xác thực và tài liệu đề xuất riêng lẻ. Ông viết rằng cùng một hành vi có thể được mô tả hơi khác nhau ở nhiều nơi, đồng thời rất khó xác định mọi khu vực bị ảnh hưởng bởi một thay đổi. Giải pháp của ông vẫn duy trì việc thảo luận ý tưởng, rà soát kỹ thuật và mọi bước phê duyệt quản trị cần thiết, trong khi bản thân thay đổi cụ thể sẽ được đưa vào một yêu cầu kéo (pull request) đối với bản đặc tả chung. Nhờ vậy, các phần mềm trình xác thực khác nhau có thể triển khai những quy tắc giống hệt nhau từ cùng một nguồn đã qua rà soát. Các yêu cầu kéo đối với bản đặc tả đã được phê duyệt sẽ vẫn mở cho đến khi thay đổi được kích hoạt trên mainnet, qua đó bảo đảm tài liệu luôn nhất quán với các quy tắc thực sự đang vận hành. Các SIMD chưa được kích hoạt sẽ chuyển sang định dạng mới nhưng vẫn giữ nguyên mã định danh, giúp tiếp tục theo dõi những đề xuất hiện có ngay cả khi bản đặc tả chung thay thế tài liệu riêng cho từng đề xuất làm tài liệu tham chiếu.

Bản dự thảo neo vào Epoch 1072

Bản dự thảo đặc tả giao thức Solana của Watt gồm 18 chương, bao quát giao dịch và thông điệp, truyền thông mạng, chuyển trạng thái và cơ chế đồng thuận, với các quy tắc tương thích ngược được tham chiếu theo epoch 1072 trên mainnet. Bản dự thảo bắt đầu từ ảnh chụp epoch đã được xác minh hoặc trạng thái được xác thực thông qua state root của epoch đó; điều này có nghĩa là niềm tin vào chính trạng thái khởi đầu là một đầu vào được cung cấp bên ngoài tài liệu. Phạm vi của tài liệu được giới hạn có chủ ý: tài liệu không đặt ra quy tắc phát lại chuỗi từ genesis, dừng ở epoch 1072 và không xác định block đầu tiên của epoch tiếp theo. Neo bản dự thảo vào một epoch giúp các quy tắc hướng tới tương lai: những thay đổi sau epoch 1072 được đối chiếu với một mốc cố định thay vì viết lại lịch sử. Kho đặc tả của Foundation cũng hướng tới mục tiêu tương tự, đó là tập hợp các quy tắc trọng yếu đối với cơ chế đồng thuận thành một tài liệu tham chiếu đầy đủ và rõ ràng mà các bản triển khai trình xác thực có thể dựa vào. Cho đến nay, các tài liệu SIMD riêng lẻ ghi lại những thay đổi quy tắc cụ thể, bao gồm SIMD-0286, đề xuất nâng giới hạn tính toán của block lên 100 triệu đơn vị tính toán. Các công việc giao thức trước đây cũng theo đuổi một mục tiêu đơn lẻ tương tự, với mục tiêu hoàn tất cuối cùng trong 150 ms của Alpenglow. Sự đa dạng của các client là bối cảnh mà Foundation nêu trong thông báo: Agave, Firedancer và Mithril là các cơ sở mã riêng biệt, và mỗi phần mềm nút trình xác thực phải cho ra cùng một kết quả từ cùng một đầu vào trong quá trình xử lý giao dịch và đồng thuận. Cùng một bộ quy tắc chi phối cách sắp xếp và thực thi giao dịch, lĩnh vực phát sinh các tác động như giá trị có thể trích xuất tối đa; sự khác biệt giữa các bản triển khai ở quy mô đó không phải là vấn đề giấy tờ mà có thể khiến chính chuỗi bị phân tách. Trọng lượng staking đứng sau các phiếu bầu của trình xác thực khiến rủi ro này vừa mang tính tài chính vừa mang tính kỹ thuật. Với những độc giả mới tìm hiểu khía cạnh này của mạng lưới, staking SOL trên Solflare cho thấy các lựa chọn client được thể hiện ra sao trong thực tế.

Việc áp dụng và thời hạn vẫn chưa được quyết định

Người tham gia alnoki lập luận trong chủ đề thảo luận công khai rằng một đặc tả bằng văn bản có thể bỏ sót các phụ thuộc nội bộ thể hiện trong những bản triển khai client, và không tài liệu đơn lẻ nào có thể nắm bắt mọi tương tác giữa chúng. Watt trả lời rằng để có đủ độ tin cậy, có thể cần xây dựng các bản triển khai thử nghiệm khái niệm song song với tài liệu, đồng thời đồng ý rằng mã định danh đề xuất nên được cấp ở giai đoạn rà soát đặc tả chính thức. Cách đánh dấu để yêu cầu rà soát lại khi đặc tả thay đổi giữa quá trình triển khai vẫn đang được xem xét. Bản thân đề xuất hiện ở bước một, ý kiến đang được thu thập và việc sửa đổi tài liệu quy trình SIMD được hoãn lại cho đến khi đạt được đồng thuận rộng rãi; chưa có quyết định nào về việc thông qua thay đổi hay lịch trình áp dụng. Vì vậy, câu hỏi vẫn trở lại ở dạng gay gắt nhất: liệu một tài liệu có thể mô tả Solana đủ chính xác để ba bản triển khai độc lập không thể bất đồng hay không? Dựa trên những gì đã được ghi nhận cho đến nay, câu trả lời vẫn còn bỏ ngỏ.