Qtum Điều chỉnh Lợi nhuận Thế chấp: Thời gian khóa càng dài thì lợi nhuận càng cao

Tiêu đề gốc: "Làm cách nào để tăng doanh thu khai thác PoS?" Đề xuất cải tiến chuỗi lượng tử Qtum số 16: Triển khai các khuyến khích khóa PoS"

Tác giả gốc:  ; Chuỗi lượng tử Qtum 

Nguồn gốc:  Chuỗi lượng tử Qtum

Đề xuất này là một đề xuất kỹ thuật mới được đăng trên Github bởi người đồng sáng lập Qtum và kỹ sư phát triển cốt lõi Jordan Earls, nhằm mục đích trợ giúpPledger( Bởi Thực hiện QIP này, Staker, có thể hiểu là “thợ đào” trong PoS, có thể đặt thời gian khóa nhất định cho token của mình và tăng khả năng nhận phần thưởng khối trong thời gian khóa.

Với sự phát triển của công nghệ blockchain, bằng chứng về sự công bằng (PoS) cơ chế đồng thuận ngày càng trở nên phổ biến. Chuỗi khối bằng chứng cổ phần cho phép chủ sở hữu mã thông báo đặt cược mã thông báo của họ, tham gia xác minh các khối như một phần của bằng chứng cổ phần và đổi lại nhận được phần thưởng tương ứng.

Một số nhà cung cấp dịch vụ và doanh nghiệp lớn được coi là Token đã cam kết không thuộc về họ về mặt kỹ thuật (và do đó nhận được phần thưởng khối). Điều này bao gồm các sàn giao dịch và nhà cung cấp ví tập trung. Bởi vì các nhà cung cấp dịch vụ này cần đảm bảo rằng họ cung cấp dịch vụ kịp thời cho người dùng và người dùng có thể rút token bất cứ lúc nào, do đó nhà cung cấp dịch vụ không thể khóa token của người dùng quá lâu.

Mặc dù hành vi cam kết token của các nhà cung cấp dịch vụ này có tác động tiêu cực đến an ninh và hệ sinh thái của toàn bộ mạng Hệ thống không gây hại gì, tuy nhiên, số lượng lớn mã thông báo mà họ kiểm soát sẽ làm tăng khó khăn trong việc đặt cược toàn bộ mạng.

Điều này cho phép các cá nhân đặt cược một lượng nhỏ mã thông báo đến Khả năng nhận được phần thưởng trở nên rất thấp. Đề xuất này sẽ giúp cải thiện khả năng cá nhân người đặt cược nhận được phần thưởng. Ngoài ra, đề xuất này còn giúp thúc đẩy người dùng cập nhật và nâng cấp các nút của họ thường xuyên, vì để nhận được nhiều hơn phần thưởng, Người dùng sẽ được yêu cầu khóa lại các mã thông báo mà họ đang đặt cược, điều này sẽ khuyến khích những người đặt cược này kiểm tra các nút đặt cược của họ và cập nhật chúng thường xuyên.

Đề xuất này cũng cung cấp tùy chọn cho phép người dùng thực hiện đặt cược cực kỳ dài hạn. Những người đặt cọc giúp bảo mật mạng có thể nhận được phần thưởng bổ sung, nhưng điều này sẽ hạn chế khả năng rút mã thông báo của họ. Ngày nay, ngày càng nhiều phụ huynh lựa chọn mua quỹ tiết kiệm giáo dục ngân hàng, đứa trẻ có thể nhận được phần thưởng cam kết từ quỹ này trong suốt năm học của mình, nhưng chỉ được tiêu số tiền thưởng thực tế khi đủ 18 tuổi. Xem phần Rủi ro để biết lý do tại sao tốt nhất không nên làm điều này (tức là tốt nhất nên hạn chế thời gian khóa số tiền đặt cọc).

Đề xuất này về mặt lý thuyết không yêu cầu bất kỳ sửa đổi đặc biệt nào về định dạng giao dịch, cũng như không yêu cầu bổ sung các opcode.  Mã opcode OP_CHECKLOCKTIME được hỗ trợ tốt bởi hệ sinh thái Bitcoin cũng như Qtum và có thể dễ dàng sử dụng Kiểm tra khóa -đến giờ rồi. Một ví dụ về tập lệnh đầu ra để khóa mã thông báo như sau:

Đây chỉ là một giao dịch pubkeyhash tiêu chuẩn, nhưng có một điều kiện tiên quyết là nó không thể được sử dụng trong Chi tiêu mã thông báo trước khi hết thời gian khóa. Tên đề xuất cho loại giao dịch này là"pay-to-lockedpubkeyhash"

Giao dịch sẽ không được chi tiêu bình thường cho đến khi hết thời gian khóa. Nhưng trong đề xuất này, giao dịch có thể được sử dụng để đặt cược. UTXO này có thể được "chi tiêu" trong một giao dịch kiếm tiền đặc biệt. Trong thực tế, các quy tắc đồng thuận cần được thêm vào để đảm bảo rằng những mã thông báo bị khóa đã được sử dụng sẽ có đầu ra mới (hoặc nhiều đầu ra) với cùng số lượng, cùng thời gian khóa và địa chỉ pubkeyhash hợp lệ.

Ví dụ: với các đầu vào này trong tiền xu:

• 10 Qtum được cấp cho A, khóa đến năm 2019

• 10 Qtum được cấp cho A, khóa đến năm 2019

• 10 Qtum cấp cho A, khóa đến năm 2021

• 5 Qtum được gửi tới B, khóa đến năm 2018 ( Đã có thể chi tiêu)

Đầu ra của giao dịch lấy tiền xu sẽ là:

• 20 Qtum cấp cho A, khóa đến năm 2019

• 10 Qtum cấp cho A, khóa đến năm 2021

• 5 Qtum được gửi tới B, khóa đến năm 2018

• 4 Qtum Gửi A , không bị khóa (phần thưởng khối)

Tất nhiên, đầu ra cũng có thể là:

• 20 Qtum cấp cho A, khóa đến năm 2019

• 5 Qtum được cấp cho A, khóa đến năm 2021

• 5 Qtum Gửi tới A, bị khóa đến năm 2021

• 2 Qtum được cấp cho B, bị khóa đến năm 2018

• 3 Qtum cấp cho B, khóa đến năm 2018

• 4 Qtum được gửi tới A, không bị khóa (khối phần thưởng)

Xin lưu ý: Để đơn giản, phần thưởng/phí chia MPoS không được phản ánh ở đây mà bởi Tổng sản lượng phần thưởng mà MPoS nhận được vẫn được gửi đến địa chỉ "A" và ở trạng thái mở khóa.

Bất kỳ mã thông báo bị khóa nào cũng có thể để chi tiêu bằng tiền xu (tất nhiên với điều kiện là quyền sở hữu khóa riêng được cung cấp), nhưng các mã thông báo bị khóa phải được xuất ra với tổng số tiền như nhau trong mỗi khoảng thời gian khóa duy nhất.

Tác động của việc khóa mã thông báo là đối với độ khó "có trọng số" của mã thông báo. Hiện tại, thuật toán trông như sau:

Thuật toán mới như sau :

Ví dụ: nếu Một đầu ra nhất định có khóaLợi ích là 0,5 QTUM, cộng với mã thông báo thực 1QTUM ban đầu trong đầu ra, tương đương với việc người dùng có 1,5 QTUM để cầm cố (mặc dù thực tế anh ta chỉ có 1QTUM), tương đương với 50% của " Khóa Nhận được".

Nên chia mức tăng bị khóa theo tới các cấp độ, ví dụ:

• 7 ngày - mức tăng bị khóa 20%

• 15 ngày - 50% lợi nhuận cố định

• 30 ngày - tăng 100% bị khóa

• 90 ngày - mức tăng bị khóa 200%

Quan trọng Có , các buff bị khóa không được cấp theo quy mô liên tiếp và phải có giới hạn cứng. Nếu không có giới hạn và tỷ lệ là 1% mỗi ngày, Sau đó, sau khi 1 mã thông báo bị khóa trong 20.000.000 ngày, nó có thể được sử dụng để thực hiện một cuộc tấn công 51% trên mạng.

Dùng "ngày" làm đơn vị thời gian để mô tả vấn đề trên nhằm giúp mọi người hiểu , nhưng trong thực tế triển khai chương trình, việc sử dụng chiều cao khối làm thước đo sẽ làm giảm đáng kể độ phức tạp của việc thực hiện. Cơ sở dữ liệu hiện có đã có chức năng truy vấn thời gian khóa khi đóng gói giao dịch. Do đó, số liệu tính theo “ngày” trên nên được thay đổi để tính toán dựa trên chênh lệch chiều cao khối tiêu chuẩn của khối mới trong 2 phút.

Loại giao dịch LockedPubKeyHash cần phải là giao dịch tiêu chuẩn, vì vậy, những người dùng chỉ nhận phần thưởng khối trung bình mỗi tháng một lần có thể ngay lập tức nhận được các lợi ích đặt cược bị khóa.

Nếu đề xuất được xác định là xứng đáng hơn nữa nghiên cứu, sau đó số tiền bị khóa sẽ được tiếp xúc với ví của người dùng sẽ được thiết kế như thế nào.

Điều này cho phép Chi tiêu mọi đầu ra bị khóa trong giao dịch tiền xu đều được thiết kế để tương thích với các kết hợp mã thông báo và thuật toán phân tách mã thông báo hiện có.

Cố gắng thực hiện càng ít thay đổi càng tốt trong thiết kế Chức năng này được thực hiện dựa trên sự đồng thuận. Chức năng locktime và checklocktime đã được chứng minh trong Bitcoin và Qtum từ lâu nên rất phù hợp để triển khai tính năng này. Thay đổi duy nhất đối với sự đồng thuận sẽ là cho phép người đặt cược Cho phép đặt cược với các mã thông báo bị khóa này và đảm bảo rằng các mã thông báo bị khóa đã sử dụng được xuất dưới dạng mã thông báo bị khóa cùng loại.

Việc thay đổi sự đồng thuận thực ra rất đơn giản, nhưng việc thay đổi ví sẽ phức tạp hơn một chút. Nếu không gặp phải khi kiểm tra và phân tích thiết kế Bất kỳ có vấn đề, thì sự thay đổi đồng thuận này (có thể có một số hạn chế nhất định về chức năng ví) có thể được đưa vào hard fork QIP-8 theo kế hoạch. Nếu nó trở nên khó khăn hơn dự kiến, có lẽ tốt hơn nên triển khai đề xuất này trong một hard fork x86.

Đầu tiên, Phân tích mô hình kinh tế cẩn thận phải được thực hiện để đánh giá mức độ gia tăng lạm phát mà đề xuất có thể dẫn đến, cũng như các tác động khác “ngoài thỏa thuận”. Bản nâng cấp này có thể gây tranh cãi trong cộng đồng, vì vậy cần phải có một cuộc bỏ phiếu trong cộng đồng để xác định ý kiến của cộng đồng về việc này Mức độ ủng hộ đối với đề xuất. Đề nghị tiến hành công việc triển khai cụ thể sau khi nhận được đa số ủng hộ.

Sử dụng mã op_CHECKLOCKTIMEVERIFY hiện có có thể gây ra sự cố Một số hiện có ví dụ về các loại giao dịch không chuẩn có những hậu quả không lường trước được, bao gồm khả năng đưa ra các thay đổi hồi tố (và nguy hiểm) đối với các giao dịch đã triển khai. Một cách tốt hơn là tạo một Nhưng có một opcode mới có ID khác. Opcode mới này chỉ hợp lệ trong bối cảnh đặt cược (nghĩa là khi đặt cược).

Nếu khóa riêng khóa mã thông báo bị rò rỉ, sẽ khó ngăn chặn kẻ tấn công việc chuyển đổi các Token này được cam kết và cạnh tranh với người dùng để nhận phần thưởng.Tất nhiên, rất khó để đảm bảo rằng người dùng có thể rút Token sang địa chỉ mới sau khi Token được mở khóa.

Nhà phát triển lõi Qtum Djaen nói rằng đề xuất này cũng có là một số rủi ro tiềm ẩn về mặt lý thuyết trong việc tăng nhẹ tập dữ liệu được sử dụng để khởi động các cuộc tấn công nghiền cổ phần (tức là dự đoán các nhà sản xuất khối tiếp theo). Trên thực tế, hiện tại đây là The tập dữ liệu vốn đã rất lớn và không thể thực hiện một cuộc tấn công mài cọc sau hơn 50 khối. Để một cuộc tấn công thành công xảy ra, cần có 500 khối để mã thông báo "trưởng thành". Mặc dù đề xuất này về mặt lý thuyết làm giảm độ khó của các cuộc tấn công, nhưng việc phát động một cuộc tấn công thành công vẫn đòi hỏi nhiều tính toán hơn mức tồn tại trong vũ trụ. Nhiều tính toán hơn. Do đó, vấn đề không lớn nhưng vẫn cần phân tích thêm.

Đề xuất này sẽ khuyến khích người dùng giữ token thay vì sử dụng token để tham gia vào hệ sinh thái. Tuy nhiên, nhiều người đang đặt cược không có ý định chi tiêu mã thông báo của họ trong thời gian ngắn trừ khi có một sự kiện thị trường lớn (tức là những người nắm giữ đã cam kết). Không rõ liệu có bất kỳ tác động sinh thái nào hay không.

Người cầm cố thường không thân thiện với đối thủ cạnh tranh. Họ có thể từ chối đóng gói các giao dịch bị khóa với mức phí thấp hơn hoặc có thể không đóng gói chúng chút nào. Những kẻ lừa đảo ác ý có thể sử dụng nó vào mục đích xấu, khiến đối thủ rơi xuống thứ hạng thấp hơn do thiếu 1 khối. nhận được. Ví dụ: nếu lớp đầu tiên bị khóa 1000 khối thì người đặt cược có thể từ chối đóng gói các giao dịch của đối thủ cạnh tranh thành các khối cho đến khi giao dịch chỉ có thể bị khóa ở 999 khối, do đó làm giảm lợi nhuận của đối thủ cạnh tranh. Để giảm thiểu vấn đề này, người ta có thể yêu cầu ví đặt "hệ số trải nghiệm" theo mặc định, chẳng hạn như 100 khối, để làm cho khối có nhiều khả năng được đưa vào bởi những người đặt cược khác trong mạng, nhưng cách tiếp cận này sẽ khiến Giao dịch bị khóa thêm một thời gian nữa. 100 khối. Một phương pháp khác là sử dụng tỷ lệ hoàn vốn thả nổi có giới hạn. Ví dụ: chỉ tối đa 1% số token bị khóa được phép hưởng thu nhập từ thời gian khóa 90 ngày nêu trên mỗi ngày.

Lâu dài tối đa cam kết Rủi ro nằm ở việc người dùng thao tác sai, chẳng hạn như ai đó vô tình khóa số tiền đã cầm cố trong hơn 10 năm. Ngay cả khi bạn quyết định triển khai tính năng này, tốt nhất là không để lộ bất kỳ cách "dễ dàng" nào để sử dụng chức năng này, người dùng buộc phải kích hoạt chức năng này bằng cách gửi một giao dịch thô (rawtransaction) để đảm bảo rằng họ hiểu đầy đủ những gì đang được thực hiện.

Hơn nữa, điều này hạn chế khả năng người dùng "bỏ phiếu" thông qua thị trường theo hướng phát triển của Qtum. Nếu người dùng không đồng ý với quyết định của đợt hard fork theo kế hoạch, họ có thể "thoát" khỏi chuỗi khối bằng cách bán mã thông báo của mình (nhưng các đồng tiền bị khóa không thể được chuyển nhượng và bán). Vấn đề này có thể được khắc phục bằng cách cho phép Mã thông báo khóa chuyển để giảm bớt. Do đó, có thể tạo thị trường thứ cấp dựa trên mã thông báo bị khóa, nhưng tính năng này có thể rủi ro hơn, khó triển khai và phân tích chính xác và có thể gây ra những hậu quả không lường trước được cho toàn bộ hệ sinh thái. Hơn nữa, nếu các mã thông báo bị khóa có thể chuyển nhượng được thì bản thân “khóa” không có ý nghĩa gì.

Đề xuất kỹ thuật này chỉ là bản nháp, các cuộc thảo luận kỹ thuật và chi tiết triển khai khác sẽ được thảo luận trong tương lai lần lượt được công bố.