@Dusk
Tôi đã nghĩ thiết kế đồng thuận của một blockchain không thể tự chống lại chính nó. Hóa ra là Dusk đã phải xây dựng bốn bản vá riêng để các trình tạo block của chính hệ thống không phá hoại lẫn nhau.
Khi tôi nhìn vào điều này lần đầu, tôi thực sự nghĩ rằng lịch trình tạo block có thể dự đoán được chủ yếu là để tối ưu hiệu suất. Vấn đề khuyến khích phía bên dưới lại còn thú vị hơn.
Đây là lý do. Dusk đã biết trước, ai được lên lịch tạo block nếu lần thử hiện tại thất bại. Điều đó không phải là lỗi; đó là cách hệ thống vẫn chạy nhanh. Nhưng điều đó cũng có nghĩa là bất kỳ ai được lên lịch cho vòng hai đều có lý do thật sự để ngồi yên và để vòng một thất bại—vì nếu làm vậy, người đó sẽ là người nhận phần thưởng.
Vì thế, Dusk đã nhúng bốn biện pháp sửa vào chính hệ thống phần thưởng. Những người cung cấp dịch vụ (provisioners) được trả tiền chỉ vì đã bỏ phiếu, kể cả trên một block cuối cùng lại bị thất bại, nên sẽ có ít lý do hơn để trì hoãn. Một phần phần thưởng của chính trình tạo phụ thuộc vào việc họ đã đưa vào bao nhiêu lượt phiếu, nên bỏ qua phiếu cũng khiến họ mất tiền. Trình tạo được lên lịch cho vòng tiếp theo sẽ bị cấm bỏ phiếu trong vòng hiện tại hoàn toàn, nên họ không thể âm thầm giúp cho việc đó thất bại. Và có giới hạn cứng về số vòng mà một lần thử tạo block có thể trải qua, nên cả trò chơi có một “trần”.
Điều làm tôi thấy thú vị hơn là Dusk không cố gắng che giấu tính dự đoán. Thay vào đó, họ thay đổi các động cơ xung quanh nó.
Sự công bằng của cơ chế đồng thuận này cũng chính là điều khiến nó có thể bị “game hóa”: biết ai sẽ đi tiếp. Dusk không xóa đi tính dự đoán đó—họ chỉ khiến việc gian lận phải trả giá nhiều hơn so với lợi ích mà nó mang lại.
tôi vẫn chưa chắc liệu điều này có còn đúng nếu hai trình tạo block được lên lịch mà rơi vào hai lượt liên tiếp trong cùng một vòng, cả hai đều với cùng một động cơ tại cùng một thời điểm. Một kẻ làm ăn xấu chỉ là một chuyện. Hai người làm đúng cùng một hướng thì là một phép thử khác.
@Dusk $DUSK #dusk
#Consensus #VOTE
Tôi đã nghĩ thiết kế đồng thuận của một blockchain không thể tự chống lại chính nó. Hóa ra là Dusk đã phải xây dựng bốn bản vá riêng để các trình tạo block của chính hệ thống không phá hoại lẫn nhau.
Khi tôi nhìn vào điều này lần đầu, tôi thực sự nghĩ rằng lịch trình tạo block có thể dự đoán được chủ yếu là để tối ưu hiệu suất. Vấn đề khuyến khích phía bên dưới lại còn thú vị hơn.
Đây là lý do. Dusk đã biết trước, ai được lên lịch tạo block nếu lần thử hiện tại thất bại. Điều đó không phải là lỗi; đó là cách hệ thống vẫn chạy nhanh. Nhưng điều đó cũng có nghĩa là bất kỳ ai được lên lịch cho vòng hai đều có lý do thật sự để ngồi yên và để vòng một thất bại—vì nếu làm vậy, người đó sẽ là người nhận phần thưởng.
Vì thế, Dusk đã nhúng bốn biện pháp sửa vào chính hệ thống phần thưởng. Những người cung cấp dịch vụ (provisioners) được trả tiền chỉ vì đã bỏ phiếu, kể cả trên một block cuối cùng lại bị thất bại, nên sẽ có ít lý do hơn để trì hoãn. Một phần phần thưởng của chính trình tạo phụ thuộc vào việc họ đã đưa vào bao nhiêu lượt phiếu, nên bỏ qua phiếu cũng khiến họ mất tiền. Trình tạo được lên lịch cho vòng tiếp theo sẽ bị cấm bỏ phiếu trong vòng hiện tại hoàn toàn, nên họ không thể âm thầm giúp cho việc đó thất bại. Và có giới hạn cứng về số vòng mà một lần thử tạo block có thể trải qua, nên cả trò chơi có một “trần”.
Điều làm tôi thấy thú vị hơn là Dusk không cố gắng che giấu tính dự đoán. Thay vào đó, họ thay đổi các động cơ xung quanh nó.
Sự công bằng của cơ chế đồng thuận này cũng chính là điều khiến nó có thể bị “game hóa”: biết ai sẽ đi tiếp. Dusk không xóa đi tính dự đoán đó—họ chỉ khiến việc gian lận phải trả giá nhiều hơn so với lợi ích mà nó mang lại.
tôi vẫn chưa chắc liệu điều này có còn đúng nếu hai trình tạo block được lên lịch mà rơi vào hai lượt liên tiếp trong cùng một vòng, cả hai đều với cùng một động cơ tại cùng một thời điểm. Một kẻ làm ăn xấu chỉ là một chuyện. Hai người làm đúng cùng một hướng thì là một phép thử khác.
@Dusk $DUSK #dusk
#Consensus #VOTE