SushiSwap cần một “cuộc đại trùng tu” khác nếu muốn thực hiện thay đổi giao thức

SushiSwap cần một cuộc đại tu khác nếu muốn thực hiện thay đổi giao thức

Quá trình di chuyển smart contract SushiSwap đã hoàn tất nhưng có một vấn đề: Có thể cần một lần di chuyển khác nếu nhóm muốn thực hiện các thay đổi đối với giao thức mà cộng đồng SushiSwap đã vote.

Cụ thể, các hạn chế trong code của SushiSwap khiến các thay đổi được đề xuất không thể thực hiện được nếu không có “cuộc đại trùng tu” đối với code, cụ thể là một cuộc di chuyển khác, công ty nghiên cứu blockchain IntoTheBlock cho biết.

Cộng đồng SushiSwap vừa bỏ phiếu để giảm phần thưởng token Sushi từ 100 SUSHI mỗi khối xuống 50, với các sự kiện Halving liên tiếp sau mỗi hai năm. Ngoài ra, sự thay đổi này sẽ bao gồm cơ chế “vesting”, theo đó 2/3 tổng số SUSHI mới được “in” sẽ bị khóa trong một năm.

Các token “vesting” này sẽ kiếm được phí giao dịch nhưng không thể được di chuyển hoặc sử dụng để vote cho đến khi thời hạn kéo dài một năm kết thúc. Được biết, đề xuất “vesting” này xuất hiện là do người tiền nhiệm của dự án, Chef Nomi đã bán 13 triệu USD SUSHI sang ETH vào cuối tuần trước.

Sushi unrolled

Những đề xuất vừa qua đã giành được đa số phiếu trong cộng đồng, nhưng IntoTheBlock cho biết các smart contract hiện tại của SushiSwap không đủ linh hoạt để “bẻ cong” các quy tắc của giao thức. Chẳng hạn, hợp đồng MasterChef không cho phép thay đổi lịch trình thưởng vì tỷ lệ phát hành đã được “hard coded.”

Trích từ bản báo cáo:

… phiên bản hiện tại của smart contract MasterChef đã “hard coded” số lượng token SUSHI được thưởng trên mỗi khối. Điều này đã được thực hiện thông qua biến sushiPerBlock được khởi tạo ở giá trị 100 tại thời điểm tạo hợp đồng và không thể sửa đổi sau đó. Bạn có thể tham chiếu tại dòng 96 của smart contract MasterChef.

Nói một cách đơn giản hơn, việc thay đổi giá trị của biến sushiPerBlock sẽ yêu cầu việc triển khai một smart contract mới.

May mắn thay, thực sự có một bản sửa lỗi cho hạn chế này mà không yêu cầu đợt di chuyển khác: Ngay cả khi phần thưởng bị giới hạn, vẫn có thể gửi thêm phần thưởng đến một địa chỉ cụt (dead-end address) mà không ai có quyền truy cập (do đó, để giảm phần thưởng từ 100 SUSHI xuống còn 50 SUSHI, mỗi phần thưởng khối sẽ gửi 50 trong số 100 SUSHI được đúc đến địa chỉ cụt này).

Mặc dù đây là cách thuận tiện, nhưng chúng không mấy chuyên nghiệp và nằm ngoài thiết kế ban đầu của giao thức SushiSwap

Cuộc đại trùng tu: Điều này có nghĩa là gì ?

Đây không phải là một kế hoạch đơn giản, việc khắc phục các hạn chế khác sẽ yêu cầu sự thay đổi hoàn toàn các smart contract của SushiSwap.

Vấn đề bắt nguồn từ một khía cạnh thiết kế, trong đó hợp đồng MasterChef (có quyền kiểm soát giao thức) không thể nâng cấp và thực sự sở hữu hợp đồng SushiToken. Vì vậy việc di chuyển sang hợp đồng MasterChef mới (ví dụ: MasterChefV2) cũng sẽ yêu cầu triển khai hợp đồng SushiToken mới (SushiTokenV2), theo nhà phát triển IntoTheBlock Pablo Bianciotto.

Người này nói rằng:

Hạn chế phát sinh do MasterChef không thể nâng cấp. Để có thể nâng cấp, hợp đồng này thực tế phải được lưu trữ trong một hợp đồng khác được tham chiếu bởi MasterChef. Điều đó sẽ cung cấp cho bạn sự linh hoạt để thay đổi logic phân phối tiền thưởng / đúc tiền bằng cách thay thế hợp đồng thứ cấp này bằng một hợp đồng mới và cập nhật tham chiếu MasterChef.

Ngoài ra, SushiToken thuộc sở hữu của MasterChef, vì vậy việc tạo hợp đồng MasterChef V2 mới với logic phân phối phần thưởng mới và các tính năng có thể nâng cấp cũng sẽ yêu cầu việc di chuyển hợp đồng SushiToken.

Ví dụ: để triển khai vesting, sẽ yêu cầu MasterChefV2  SushiTokenV2.

Bên cạnh đó, hạn chế của code cũng sẽ cản trở việc thực hiện đề xuất thanh toán phí vì không có cách nào để chuyển các token được cấp từ hợp đồng MasterChef sang một hợp đồng khác để đóng phí. Và:

Phần này thậm chí còn khó thực hiện hơn.

Cộng đồng nói gì?

Chúng tôi đã liên hệ với ban lãnh đạo mới được bầu của SushiSwap (những thành viên nắm giữ chín khóa multisig, có quyền thực hiện lệnh thay đổi giao thức) để hỏi xem họ có đang lên kế hoạch cho một đợt di chuyển khác hay không.

0xMaki – nhà phát triển chính của SushiSwap, người đã đồng hành cùng dự án ngay từ đầu – trả lời: “Không có sự di chuyển khác trong ngắn hạn”. 0xMaki tiếp tục rằng họ muốn thực hiện các đề xuất vesting và fee-staking nhưng “nó sẽ đòi hỏi nhiều cuộc thảo luận hơn”.

Tuy nhiên, Bianciotto đã khẳng định “dường như cách duy nhất để thực hiện những đề xuất này  là thực hiện một cuộc di chuyển”.

Để chứng thực cho nghiên cứu của IntoTheBlock, CoinDesk đã liên hệ với Zokyo Labs, một công ty phát triển và bảo mật blockchain; và đại diện của Zokyo đã xác nhận những phát hiện của IntoTheBlock.


Có thể bạn quan tâm:

CÓ THỂ BẠN QUAN TÂM