Skip to main content

Quản trị trên chuỗi (CIP-1694)

TÓM TẮT​

Chúng tôi đề xuất sửa đổi hệ thống quản trị trên chuỗi của Cardano để hỗ trợ các yêu cầu mới cho Voltaire. Hỗ trợ quản trị chuyên biệt hiện có cho các cập nhật tham số giao thức, chứng chỉ MIR sẽ bị xóa và hai trường mới sẽ được thêm vào các nội dung giao dịch thông thường:

  1. Đề xuất quản trị
  2. Phiếu bầu

Bất kỳ người dùng Cardano nào cũng sẽ được phép gửi Đề xuất quản trị. Chúng tôi cũng giới thiệu ba cơ quan quản trị riêng biệt với các chức năng khác nhau:

  1. Ủy ban hiến pháp
  2. Nhóm đại diện ủy quyền (được gọi là DReps)
  3. Nhóm điều hành pool cổ phần (được gọi là SPO)

Mọi Đề xuất quản trị phải được phê chuẩn bởi hai trong số ba cơ quan quản trị này thông qua việc sử dụng phiếu bầu của họ. Tùy thuộc loại Đề xuất và trạng thái của hệ thống quản trị sẽ xác định cơ quan nào phải phê chuẩn chúng.

Các Đề xuất được phê chuẩn sau đó có thể được ban hành trên chuỗi, tuân theo một bộ quy tắc được xác định rõ ràng.

Giống như Stake pool, bất kỳ chủ sở hữu ADA nào cũng có thể đăng ký trở thành DRep và trở thành người đại diện của các chủ sở hữu ADA khác. Tương tự như với Stake pool, họ cũng có thể ủy quyền quyền biểu quyết của mình cho bất kỳ DRep đã đăng ký nào khác. Các quyền biểu quyết này sẽ dựa trên tổng số cổ phần ADA của họ, được tính theo Lovelace.

Do đó, khía cạnh quan trọng nhất của đề xuất này là định nghĩa "một Lovelace = một phiếu bầu".

Video về Video về Hội thảo cộng đồng CIP-1694

Mục tiêu​

Chúng ta đang bước vào thời đại của Voltaire, đặt nền móng cho việc ra quyết định phi tập trung. CIP này mô tả một cơ chế quản trị trên chuỗi sẽ củng cố giai đoạn Voltaire của Cardano. Tài liệu này được xây dựng dựa trên và mở rộng sơ đồ quản trị Cardano ban đầu dựa trên một số khóa quản trị cố định. Nó nhằm mục đích cung cấp một bước đầu tiên có giá trị và quan trọng là cũng có thể đạt được về mặt kỹ thuật trong thời gian tới như một phần của hệ thống quản trị Voltaire được đề xuất.

Nó cũng tìm cách hoạt động như một điểm xuất phát để tiếp tục đóng góp ý kiến ​​của cộng đồng, bao gồm cả cài đặt ngưỡng thích hợp và các cài đặt trên chuỗi khác.

Các đề xuất tiếp theo có thể điều chỉnh và mở rộng đề xuất này để đáp ứng các nhu cầu quản trị mới nổi.

Thiết kế cơ chế quản trị hiện tại​

Cơ chế quản trị Cardano trên chuỗi được giới thiệu trong epoch sổ cái Shelley gồm các chức năng:

  1. Sửa đổi giá trị của các tham số trong giao thức (bao gồm cả việc bắt đầu "hardforks")
  2. Chuyển ADA ra khỏi quỹ dự trữ và ngân quỹ (đồng thời chuyển ADA giữa quỹ dự trữ và ngân quỹ)

Trong sơ đồ hiện tại, các Đề xuất quản trị được bắt đầu bởi các giao dịch đặc biệt yêu cầu Quorum-Many ủy quyền từ các khóa quản trị (5 trên 7 trên mạng chính Cardano)[^1]. Các trường trong nội dung giao dịch cung cấp thông tin chi tiết về Đề xuất quản trị được đề xuất: thay đổi thay đổi tham số giao thức hoặc bắt đầu chuyển tiền. Mỗi giao dịch có thể kích hoạt chính xác một loại Đề xuất quản trị, nhưng một hành động đơn lẻ có thể có nhiều hơn một tác động (ví dụ: thay đổi hai hoặc nhiều tham số giao thức).

Các Đề xuất quản trị được ủy quyền hợp lệ sẽ có hiệu lực hi chuyển sang epoch mới (Nếu chúng được ban hành).

Hardfork​

Một trong các tham số giao thức rất quan trọng đáng được chú ý đặc biệt: việc thay đổi phiên bản giao thức chính cho phép Cardano thực hiện các hardfork có kiểm soát. Do đó, loại cập nhật tham số giao thức này có một trạng thái đặc biệt, vì các Stake pool phải nâng cấp các phiên bản node của họ để hỗ trợ phiên bản giao thức mới sau khi hardfork được ban hành.

Những thiếu sót của thiết kế quản trị Shelley​

Thiết kế hiện tại nhằm cung cấp một cách tiếp cận chuyển đổi, đơn giản để quản trị. Đề xuất này nhằm mục đích giải quyết một số thiếu sót với thiết kế rõ ràng đó khi chúng ta chuyển sang Voltaire.

  1. Thiết kế quản trị Shelley chưua trao cơ hội cho những người nắm giữ ADA tham gia tích cực vào quản trị trên chuỗi. Mặc dù các thay đổi đối với giao thức thường là kết quả của các cuộc thảo luận với các tác nhân cộng đồng được chọn, nhưng quá trình này chủ yếu được thúc đẩy bởi các thực thể sáng lập. Việc đảm bảo rằng mọi người đều có thể nói lên mối quan tâm của mình là một việc rườm rà và đôi khi có thể bị coi là tùy tiện.
  2. Các giao dịch rút tiền từ ngân quỹ là một chủ đề quan trọng và nhạy cảm. Tuy nhiên, chúng có thể khó theo dõi. Điều quan trọng là phải minh bạch hơn và có nhiều lớp kiểm soát hơn đối với các chuyển động này.
  3. Mặc dù chúng cần được SPO xử lý đặc biệt, nhưng các hardfork không được phân biệt với các thay đổi tham số giao thức khác.
  4. Cuối cùng, mặc dù hiện tại có một tầm nhìn chung cho Cardano được chia sẻ bởi các tổ chức sáng lập và cũng bởi nhiều thành viên cộng đồng, nhưng không có tài liệu xác định rõ ràng nơi các nguyên tắc hướng dẫn này được ghi lại. Thật hợp lý khi tận dụng blockchain Cardano để ghi lại các đặc tính Cardano được chia sẻ theo cách bất biến, như một Hiến pháp Cardano chính thức.

Các vấn đề nằm ngoài phạm vi​

Các chủ đề sau đây được coi là nằm ngoài phạm vi của đề xuất này.

Nội dung hiến pháp​

CIP này chỉ tập trung vào các cơ chế Quản trị trên chuỗi. Các điều khoản của hiến pháp ban đầu là cực kỳ quan trọng, cũng như bất kỳ quy trình nào cho phép nó được sửa đổi. Những điều này xứng đáng với cuộc thảo luận riêng biệt và tập trung chuyên sâu hơn.

Thành viên của Ủy ban hiến pháp​

Đây là một vấn đề ngoài chuỗi cũng như ngoài phạm vi của đề xuất này.

Vấn đề pháp lý​

Bất kỳ khả năng thực thi pháp lý nào đối với giao thức Cardano hoặc Hiến pháp Cardano đều hoàn toàn nằm ngoài phạm vi của CIP này.

Các tiêu chuẩn ngoài chuỗi cho các Đề xuất quản trị​

Cộng đồng Cardano phải suy nghĩ sâu sắc về các tiêu chuẩn và quy trình chính xác để xử lý việc tạo ra các Đề xuất quản trị được chỉ định trong CIP này. Đặc biệt, vai trò của Project Catalyst trong việc tạo ra các hành động rút tiền ngân quỹ hoàn toàn nằm ngoài phạm vi của CIP này.

ADA nắm giữ và ủy quyền​

Cách bất kỳ công ty tư nhân, tổ chức công cộng hoặc tư nhân, cá nhân, v.v. chọn nắm giữ hoặc ủy quyền ADA của họ, bao gồm ủy quyền cho Stake pool hoặc DReps, nằm ngoài phạm vi của CIP này.

Các vấn đề cụ thể​

Hiến pháp Cardano​

Hiến pháp Cardano là một tài liệu văn bản xác định các giá trị chung và nguyên tắc hướng dẫn của Cardano. Ở giai đoạn này, Hiến pháp là một tài liệu thông tin nắm bắt rõ ràng các giá trị cốt lõi của Cardano và hành động để đảm bảo tính bền vững lâu dài của nó. Ở giai đoạn sau, chúng ta có thể hình dung Hiến pháp có thể phát triển thành một bộ quy tắc dựa trên hợp đồng thông minh để thúc đẩy toàn bộ khuôn khổ quản trị. Tuy nhiên, hiện tại, Hiến pháp sẽ vẫn là một tài liệu ngoài chuỗi có giá trị thông báo hash sẽ được ghi lại trên chuỗi. Như đã thảo luận ở trên, Hiến pháp vẫn chưa được xác định và nội dung của nó nằm ngoài phạm vi của CIP này.

Ủy ban hiến pháp​

Chúng tôi xác định một Ủy ban hiến pháp đại diện cho một tập hợp các cá nhân hoặc tổ chức (mỗi người được liên kết với một cặp thông tin đăng nhập Ed25519) chịu trách nhiệm chung để đảm bảo rằng Hiến pháp được tôn trọng.

Mặc dù nó không thể được thực thi trên chuỗi, nhưng Ủy ban hiến pháp chỉ có nhiệm vụ bỏ phiếu về tính hợp hiến của các Đề xuất quản trị và họ sẽ bị thay thế (thông qua hành động bất tín nhiệm) nếu họ vượt qua sang này. Nói cách khác, có một hợp đồng xã hội giữa Ủy ban hiến pháp và các tác nhân của mạng lưới. Mặc dù Ủy ban hiến pháp có thể từ chối một số Đề xuất quản trị nhất định (bằng cách bỏ phiếu không cho các đề xuất), nhưng họ chỉ nên làm như vậy khi những Đề xuất quản trị đó mâu thuẫn với Hiến pháp.

Ví dụ: nếu chúng ta xem xét quy tắc Hiến pháp giả định "Mạng Cardano phải luôn có khả năng tạo ra các khối mới", thì một Đề xuất quản trị làm giảm kích thước khối tối đa xuống mức thực tế sẽ là vi hiến và do đó có thể không được phê chuẩn bởi Ủy ban hiến pháp. Tuy nhiên, quy tắc không chỉ định kích thước khối tối đa nhỏ nhất có thể chấp nhận được, vì vậy Ủy ban hiến pháp sẽ cần xác định con số này và bỏ phiếu tương ứng.

Trạng thái Bất tín nhiệm​

Ủy ban hiến pháp được coi là luôn ở một trong hai trạng thái sau:

  1. Trạng thái bình thường (tức là Tín nhiệm)
  2. Trạng thái Bất tín nhiệm

Trong Trạng thái bất tín nhiệm, Ủy ban hiện tại không thể tham gia vào các Đề xuất quản trị nữa và phải được thay thế trước khi bất kỳ Đề xuất quản trị nào có thể được phê chuẩn (xem bên dưới). Bất kỳ Đề xuất quản trị nổi bật nào đều bị hủy bỏ ngay sau khi giao thức chuyển sang trạng thái Bất tín nhiệm và đề xuất sẽ không được ban hành.

Ủy ban hiến pháp sẽ sử dụng thiết lập khóa nóng và lạnh, tương tự như cơ chế "chứng chỉ ủy quyền ban đầu" hiện có.

Ủy ban hiến pháp ban đầu​

Ủy ban ban đầu vẫn chưa được xác định. Rất có thể, nó sẽ bao gồm một số thực thể sáng lập của Cardano.

Thay thế Ủy ban hiến pháp​

Ủy ban hiến pháp có thể được thay thế bằng một trong hai cách sau:

  • Khi ở trạng thái bình thường (nghĩa là trạng thái tin cậy), Ủy ban có thể được thay thế thông qua một Đề xuất quản trị cụ thể (hành động 2 bên dưới) cần có sự chấp thuận của cả Ủy ban hiến pháp hiện tại và DReps.
  • Khi ở trạng thái bất tín nhiệm, Ủy ban cũng có thể được thay thế thông qua Đề xuất quản trị tương tự (hành động 2 bên dưới), nhưng thay vào đó, điều này cần có sự chấp thuận của cả SPO và DReps.

Quy mô của Ủy ban hiến pháp​

Không giống như thiết kế quản trị Shelley, quy mô của Ủy ban hiến pháp không cố định. Nó có thể được thay đổi bất cứ khi nào một Ủy ban mới được bầu (hành động 2 bên dưới). Tương tự như vậy, số đại biểu cần thiết của Ủy ban (số Chấp thuận phiếu bầu của Ủy ban được yêu cầu để phê chuẩn các Đề xuất quản trị) không cố định và cũng có thể thay đổi theo Đề xuất quản trị 2. Điều này mang lại sự linh hoạt lớn cho thành phần của Ủy ban.

Giới hạn nhiệm kỳ​

Hệ thống sẽ tự động chuyển sang trạng thái bất tín nhiệm khi hết thời hạn nhiệm kỳ của Ủy ban hiến pháp. Giới hạn này là một tham số giao thức quản trị, chỉ định số lượng epoch tối đa trong đó Ủy ban có thể phê chuẩn các Đề xuất quản trị. Khi giới hạn nhiệm kỳ của Ủy ban hết hạn, tất cả các Đề xuất quản trị sẽ bị hủy bỏ và một Ủy ban mới phải được bầu.

Giới hạn nhiệm kỳ sẽ được đặt lại bất cứ khi nào Đề xuất quản trị 2 được ban hành, ngay cả khi chính Ủy ban đó được bầu lại và số đại biểu không thay đổi. Điều này cho phép những người nắm giữ ADA xác nhận sự tin tưởng của họ đối với Ủy ban nếu họ muốn. Lưu ý rằng giới hạn nhiệm kỳ được tính tại thời điểm Ủy ban được bầu. Bất kỳ thay đổi nào trong tham số giao thức cơ bản chỉ ảnh hưởng đến điều khoản áp dụng cho các Ủy ban trong tương lai.

Đại diện được ủy quyền (DReps)​

Cảnh báo

Không nên kết hợp CIP-1694 DReps với Project Catalyst DReps.

DRep được xác định trước​

Để tham gia quản trị, mỗi chứng chỉ cổ phần phải được ủy quyền cho một DRep. Chủ sở hữu ADA thường sẽ ủy quyền quyền biểu quyết của họ cho một DRep đã đăng ký sẽ bỏ phiếu thay mặt họ. Ngoài ra, có sẵn hai tùy chọn DRep được xác định trước:

  • Abstain (Phiếu trắng)

    Nếu chủ sở hữu ADA ủy quyền cho Abstain, thì cổ phần của họ được kích hoạt đánh dấu là không tham gia quản trị.

    Tác dụng của việc ủy ​​quyền Abstain trên chuỗi là cổ phần được ủy quyền này sẽ không được coi là một phần của cổ phần biểu quyết đang hoạt động. Tuy nhiên, cổ phần sẽ được coi là đã được đăng ký cho mục đích của các ưu đãi được mô tả trong Các ưu đãi để ủy quyền cổ phần biểu quyết.

  • No Confidence (Bất tín nhiệm)

    Nếu chủ sở hữu ADA ủy quyền cho No Confidence, thì cổ phần của họ được tính là một phiếu Chống (Không đồng ý) bầu cho mọi Đề xuất quản trị ngoại trừ kiến ​​nghị bất tín nhiệm (hành động 1). Điều này cũng báo hiệu rằng họ bất tín nhiệm vào Ủy ban hiến pháp hiện có.

    Tác dụng của việc ủy ​​thác No Confidence trên chuỗi là cổ phần này sẽ được coi là một phần của cổ phần biểu quyết đang hoạt động. Nó sẽ được tính là một phiếu Thuận (Đồng ý) bầu cho mọi No Confidence (bất tín nhiệm) hành động và một phiếu Chống (Không đồng ý) bầu cho mọi hành động khác. Nó cũng phục vụ như một biện pháp có thể kiểm tra trực tiếp về độ tin cậy của Ủy ban hiến pháp tại mọi thời điểm.

Lưu ý Bất kỳ chủ sở hữu ADA nào cũng có thể đăng ký thông tin xác thực cổ phần của họ dưới dạng DRep và ủy quyền cho chính họ nếu họ muốn tham gia tích cực vào việc bỏ phiếu.

DRep đã đăng ký​

Trong Voltaire, thông tin đăng nhập cổ phần hiện có cũng sẽ có thể ủy quyền cổ phần của họ cho DReps đã đăng ký. Ủy quyền DRep sẽ bắt chước các cơ chế ủy quyền staking hiện có (thông qua chứng chỉ trên chuỗi). Tương tự, đăng ký DRep sẽ bắt chước các cơ chế đăng ký staking hiện tại.

DReps đã đăng ký được xác định bằng thông tin xác thực có thể là:

  • Khóa xác minh (Ed25519)
  • Tập lệnh gốc hoặc Plutus

Thông báo hash (hash) blake2b-224 của chứng chỉ DRep được tuần tự hóa được gọi là DRep ID.

Các loại chứng chỉ mới sau đây sẽ được thêm vào để quản trị:

Giấy chứng nhận đăng ký DRep​

Giấy chứng nhận đăng ký DRep bao gồm:

  • ID DRep
  • Một Anchor

Một Anchor là một cặp:

  • Một URL tới tệp JSON của siêu dữ liệu
  • Hàm hash (hash) nội dung của URL siêu dữ liệu này

Cấu trúc và định dạng của siêu dữ liệu này được cố tình bỏ ngỏ trong CIP này. Các quy tắc trên chuỗi sẽ không kiểm tra URL hoặc hàm hash. Tuy nhiên, các ứng dụng máy chạm phải thực hiện kiểm tra độ chính xác thông thường khi tìm nạp nội dung từ URL được cung cấp.

Giấy chứng nhận hưu trí DRep​

Giấy chứng nhận ngừng hoạt động DRep bao gồm:

  • ID DRep
  • Số epoch mà sau đó DRep sẽ ngừng hoạt động
Giấy chứng nhận ủy quyền bầu cử​

Giấy chứng nhận ủy quyền bỏ phiếu bao gồm:

  • ID DRep mà cổ phần sẽ được ủy quyền
  • Chứng chỉ cổ phần cho người được ủy quyền

Sơ đồ ủy quyền (nghĩa là chữ ký nào được yêu cầu để đăng ký, ngừng hoạt động hoặc ủy quyền) bắt chước sơ đồ ủy quyền chứng chỉ ủy quyền giáo khu hiện có.

Phân bổ cổ phần mới cho DReps​

Ngoài phân phối thông tin xác thực trên mỗi cổ phần hiện có và phân phối trên mỗi Stake pool, giờ đây sổ cái cũng sẽ xác định phân bổ cổ phần trên mỗi DRep. Phân phối này sẽ xác định số cổ phần được hỗ trợ bởi mỗi Đồng ý phiếu bầu từ DRep.

Cảnh báo

Không giống như phân phối được sử dụng để sản xuất khối, chúng ta sẽ luôn sử dụng phiên bản mới nhất của phân bổ cổ phần trên mỗi DRep như được đưa ra thời điểm chuyển tiếp epoch.

Điều này có nghĩa là đối với bất kỳ chủ đề nào mà các cử tri cá nhân quan tâm sâu sắc, họ có thời gian để đăng ký làm DRep và bỏ phiếu trực tiếp. Tuy nhiên, điều đó có nghĩa là có thể có sự khác biệt giữa cổ phần được sử dụng để sản xuất khối và cổ phần được sử dụng để bỏ phiếu trong bất kỳ epoch nhất định nào.

Khuyến khích ủy quyền biểu quyết​

Sau giai đoạn khởi động, các tài khoản phần thưởng sẽ bị chặn rút bất kỳ phần thưởng nào trừ khi thông tin xác thực cổ phần liên quan của chúng cũng được ủy quyền cho DRep (được xác định trước hoặc đã đăng ký). Điều này giúp đảm bảo sự tham gia cao, và do đó, tính hợp pháp.

Ưu đãi DRep​

DReps được cho là cần phải được bù đắp cho công việc của họ. Nghiên cứu về các mô hình khuyến khích vẫn đang được tiến hành và chúng ta sẽ không muốn triển khai CIP này trước khi vấn đề này được giải quyết.

Do đó, đề xuất tạm thời của chúng tôi là sử dụng Lovelace từ ngân quỹ Cardano hiện tại cho đến khi quyết định cực kỳ quan trọng này có thể được cộng đồng đồng ý, thông qua cơ chế quản trị trên chuỗi đang được xây dựng.

Ngoài ra, DReps có thể tự thanh toán thông qua các trường hợp của hành động rút tiền ngân quỹ (hành động 6) được mô tả trong CIP này. Một hành động như vậy sẽ có thể kiểm tra được trên chuỗi và phải phản ánh một thỏa thuận ngoài chuỗi giữa DReps và người được ủy quyền.

Đề xuất quản trị​

Chúng tôi xác định bảy loại Đề xuất quản trị khác nhau. Một Đề xuất quản trị là một sự kiện trên chuỗi được kích hoạt bởi một giao dịch và có thời hạn nếu sau đó nó không thể được ban hành.

  • Một hành động được cho là đã được phê chuẩn khi nó thu thập đủ số phiếu ủng hộ (thông qua các quy tắc và thông số được trình bày chi tiết bên dưới).
  • Một hành động không thu thập đủ số phiếu thuận (Đồng ý) trước thời hạn sẽ được công nhận là hết hạn.
  • Một hành động đã được phê chuẩn được cho là được ban hành sau khi nó đã được kích hoạt trên mạng.

Bất kể chúng đã được phê chuẩn hay chưa, các hành động có thể bị hủy bỏ mà không được ban hành nếu một kiến ​​nghị bất tín nhiệm được ban hành.

Hoạt độngMô tả
1. Kiến nghị bất tín nhiệmMột kiến ​​nghị nhằm tạo ra tình trạng bất tín nhiệm đối với Ủy ban hiến pháp hiện tại
2. Ủy ban hiến pháp mới và/hoặc quy mô đại biểuThay đổi thành viên của Ủy ban hiến pháp và/hoặc ngưỡng chữ ký của Ủy ban
3. Cập nhật Hiến phápMột sửa đổi đối với Hiến pháp ngoài chuỗi, được ghi dưới dạng hàm hash trên chuỗi của tài liệu văn bản
4. Bắt đầu Hard-Fork[^2]Kích hoạt nâng cấp mạng không tương thích ngược; yêu cầu nâng cấp phần mềm trước
5. Thay đổi thông số giao thứcBất kỳ thay đổi nào đối với một hoặc nhiều tham số giao thức có thể cập nhật, ngoại trừ các thay đổi đối với các phiên bản giao thức chính ("hardforks")
6. Rút tiền ngân quỹCác chuyển động từ ngân quỹ, được phân loại thành các khoản rút tiền nhỏ, trung bình hoặc lớn (dựa trên số lượng Lovelace được rút). Các ngưỡng rút tiền ngân quỹ được thảo luận dưới đây.
7. Thông tinMột hành động không có tác dụng trên chuỗi, ngoại trừ một bản ghi trên chuỗi.

Bất kỳ chủ sở hữu ADA nào cũng có thể gửi Đề xuất quản trị chuỗi. Họ phải cung cấp một khoản đặt cọc bằng govDeposit Lovelace, số tiền này sẽ được trả lại khi hành động được hoàn tất (cho dù hành động đó được phê chuẩn, bị hủy bỏ hay hết hạn). Số tiền gửi sẽ được thêm vào quỹ tiền gửi, tương tự như tiền gửi khóa cổ phần.

Lưu ý rằng kiến ​​nghị bất tín nhiệm là một biện pháp cực đoan cho phép những người nắm giữ ADA thu hồi quyền lực đã được trao cho Ủy ban hiến pháp hiện tại. Bất kỳ Đề xuất quản trị nổi bật nào, bao gồm cả những hành động mà Ủy ban đã phê chuẩn hoặc những hành động sẽ được ban hành vào thời kỳ này, sẽ bị hủy bỏ nếu kiến ​​nghị được ban hành.

Phê chuẩn​

Các Đề xuất quản trị được phê chuẩn thông qua các hành động bỏ phiếu trên chuỗi. Các loại Đề xuất quản trị khác nhau có các yêu cầu phê chuẩn khác nhau nhưng luôn có sự tham gia của hai trong số ba cơ quan quản trị. Tùy thuộc vào loại Đề xuất quản trị, do đó, một hành động sẽ được phê chuẩn khi xảy ra sự kết hợp của những điều sau:

  • Ủy ban hiến pháp chấp thuận hành động (có nhiều thành viên bỏ phiếu Đồng ý)
  • DReps chấp thuận hành động (cổ phần được kiểm soát bởi DReps bỏ phiếu Đồng ý đáp ứng một ngưỡng nhất định trong tổng số cổ phần biểu quyết đã đăng ký)
  • Các SPO chấp thuận hành động (cổ phần được kiểm soát bởi các SPO bỏ phiếu Đồng ý đáp ứng một ngưỡng nhất định trên tổng số cổ phần biểu quyết đã đăng ký)
Cảnh báo

Như được giải thích bên dưới, các phân bổ cổ phần khác nhau áp dụng cho DReps và SPO.

Yêu cầu​

Bảng sau đây nêu chi tiết các yêu cầu phê chuẩn cho từng kịch bản Đề xuất quản trị. Các cột đại diện cho:

  • Governance action type Loại Đề xuất quản trị. Lưu ý rằng các bản cập nhật tham số giao thức được nhóm thành ba loại.
  • Ủy ban hiến pháp (viết tắt là CC) Giá trị ✓ thể hiện rằng cần phải có nhiều phiếu bầu Đồng ý của Ủy ban hiến pháp. Giá trị của (-) có nghĩa là phiếu bầu của Ủy ban hiến pháp không có tác dụng.
  • DReps Ngưỡng biểu quyết DRep phải được đáp ứng dưới dạng phần trăm cổ phần biểu quyết đang hoạt động. Giá trị của (-) có nghĩa là phiếu bầu DReps không có tác dụng.
  • SPO Ngưỡng bỏ phiếu SPO phải được đáp ứng theo tỷ lệ phần trăm cổ phần được nắm giữ bởi tất cả các Stake pool. Giá trị của (-) có nghĩa là phiếu bầu SPO không có tác dụng.
Loại Đề xuất quản trịCCDRepSPO
1. Kiến nghị bất tín nhiệm-P1Q1
2 một. Ủy ban/đại biểu mới (trạng thái bình thường)✓P2a-
2b. Ủy ban/số đại biểu mới (trạng thái bất tín nhiệm)-P2bQ2b
3. Cập nhật Hiến pháp✓P3-
4. Bắt đầu hardforks✓P4Q4
5a. Thay đổi tham số giao thức, nhóm mạng✓P5a-
5b. Thay đổi tham số giao thức, nhóm kinh tế✓P5b-
5c. Thay đổi tham số giao thức, nhóm kỹ thuật✓P5c-
5d. Thay đổi tham số giao thức, nhóm quản trị✓P5d-
6. Rút tiền ngân quỹ✓P6-
7. Thông tin✓P7-
Cảnh báo 

Đối với việc rút tiền từ ngân quỹ, ngưỡng rút tiền là tổng số Lovelace được rút theo hành động, không phải số tiền của bất kỳ lần rút tiền nào nếu hành động chỉ định nhiều hơn một lần rút tiền.

Mỗi ngưỡng này là một tham số quản trị. Các ngưỡng ban đầu nên được chọn bởi toàn bộ cộng đồng Cardano.

Lưu ý Có thể hợp lý đối với một số hoặc tất cả các ngưỡng thích ứng đối với Lovelace được đăng ký tích cực để bỏ phiếu. Ví dụ: ngưỡng có thể khác nhau giữa 51% đối với mức đăng ký cao và 75% đối với mức đăng ký thấp. Ngoài ra, ngưỡng ngân quỹ cũng có thể thích ứng, tùy thuộc vào tổng số Lovelace đang được rút hoặc các ngưỡng khác nhau có thể được đặt cho các mức rút tiền khác nhau.

Những hạn chế​

Ngoài Rút tiền từ ngân quỹ và Thông tin, chúng ta còn bao gồm một cơ chế để đảm bảo rằng các Đề xuất quản trị cùng loại không vô tình xung đột với nhau theo cách không mong muốn.

Mỗi Đề xuất quản trị phải bao gồm ID Đề xuất quản trị trước đó thuộc loại nhất định. Điều này có nghĩa là hai hành động cùng loại có thể được ban hành cùng một lúc, nhưng chúng phải được thiết kế có chủ ý để làm như vậy.

Ban hành​

Các hành động đã được phê chuẩn trong epoch hiện tại được ưu tiên ban hành như sau:

  1. Kiến nghị bất tín nhiệm
  2. Ủy ban/Đại biểu mới
  3. Cập nhật Hiến pháp
  4. Bắt đầu HardFork
  5. Thay đổi tham số giao thức
  6. Rút tiền ngân quỹ
  7. Thông tin

Lưu ý Không có sự ban hành nào đối với các hành động Thông tin vì chúng không có bất kỳ ảnh hưởng nào đến giao thức.

Một Kiến nghị bất tín nhiệm thành công, bầu cử một Ủy ban hiến pháp mới hoặc thay đổi hiến pháp sẽ vô hiệu hóa *tất cả các Đề xuất quản trị *chưa được ban hành khác (dù chúng đã được phê chuẩn hay chưa), khiến chúng bị hủy bỏ ngay lập tức mà không bao giờ được ban hành. Tiền gửi cho các hành động bị từ chối sẽ được trả lại ngay lập tức.

Vòng đời​

Các Đề xuất quản trị chỉ được kiểm tra để phê chuẩn tại thời điểm chuyển đổi epoch. Sau khi được phê chuẩn, các hành động được tổ chức để ban hành.

Do đó, tất cả các Đề xuất quản trị được đệ trình sẽ:

  1. Được phê chuẩn, sau đó ban hành
  2. Được phê chuẩn, nhưng bị loại bỏ do một số hành động có mức độ ưu tiên cao hơn
  3. Hết hạn sau một số epoch nhất định

Tiền gửi được trả lại ngay lập tức khi:

  1. Một hành động phê chuẩn được ban hành
  2. Hành động hết hạn
  3. Một hành động phê chuẩn bị hủy bỏ

Một số hành động sẽ được ban hành ngay lập tức (tức là tại cùng epoch mà chúng được phê chuẩn), các hành động khác chỉ được ban hành tại thời điểm chuyển sang epoch tiếp theo.

Loại Đề xuất quản trịban hành
1. Kiến nghị bất tín nhiệmNgay tức khắc
2. Ủy ban mới/của aiNgay tức khắc
3. Cập nhật Hiến phápNgay tức khắc
4. Bắt đầu hardforksSang epoch tiếp theo
5. Thay đổi thông số giao thứcSang epoch tiếp theo
6. Rút tiền ngân quỹNgay tức khắc
7. Thông tinNgay tức khắc

Nội dung​

Mỗi Đề xuất quản trị sẽ bao gồm những điều sau đây:

  • Số tiền gửi (được ghi lại vì số tiền gửi là một tham số giao thức có thể cập nhật)
  • Một địa chỉ phần thưởng để nhận tiền gửi khi nó được hoàn trả
  • Một Anchor cho bất kỳ siêu dữ liệu nào cần thiết để biện minh cho hành động
  • Một giá trị phân loại hash để ngăn xung đột với các hành động cạnh tranh cùng loại (như được mô tả trước đó)

Ngoài ra, mỗi hành động sẽ bao gồm một số yếu tố dành riêng cho loại của nó:

Loại Đề xuất quản trịDữ liệu bổ sung
1. Kiến nghị bất tín nhiệmKhông có
2. Ủy ban/Đại biểu mớiTập hợp các thông báo hash chính xác minh và số đại biểu
3. Cập nhật Hiến phápMột bản tóm tắt hash của tài liệu Hiến pháp
4. Bắt đầu hardforksPhiên bản giao thức chính mới (lớn hơn)
5. Thay đổi thông số giao thứcCác thông số thay đổi
6. Rút tiền ngân quỹBản đồ từ thông tin đăng nhập cổ phần đến số lượng Lovelace dương
7. Thông tin

Mỗi Đề xuất quản trị được chấp nhận sẽ được chỉ định một mã định danh duy nhất (còn gọi là ID Đề xuất quản trị), bao gồm hàm hash giao dịch đã tạo ra hành động đó và chỉ mục trong nội dung giao dịch trỏ đến hành động đó.

Nhóm tham số giao thức​

Chúng tôi đã nhóm các thay đổi tham số giao thức. Điều này cho phép đặt các ngưỡng khác nhau cho từng nhóm và cũng hỗ trợ các phiếu bầu riêng biệt. DReps có thể chọn bỏ phiếu trắng đối với các thay đổi tham số nằm ngoài lĩnh vực chuyên môn của họ. Các nhóm tham số mạng, kinh tế và kỹ thuật thu thập các tham số giao thức hiện có đã được giới thiệu trong thời đại Shelley, Alonzo và Babbage. Ngoài ra, chúng tôi giới thiệu một nhóm Quản trị mới dành riêng cho các thông số quản trị mới sẽ được giới thiệu bởi CIP-1694.

Nhóm Mạng bao gồm:

  • Kích thước khối tối đa (maxBBSize)
  • Kích thước giao dịch tối đa (maxTxSize)
  • Kích thước tiêu đề khối tối đa (maxBHSize)
  • Epoch ngừng hoạt động tối đa của pool (eMax)
  • Số lượng pool mong muốn (nOpt)
  • Các mô hình chi phí thực hiện của Plutus (costModels)
  • Kích thước tối đa của giá trị tài sản được đánh số thứ tự (maxValSize)
  • Số lượng đầu vào tài sản thế chấp tối đa (maxCollateralInputs)
  • Đơn vị thực thi tập lệnh tối đa trong một giao dịch (maxTxExUnits)
  • Đơn vị thực thi tập lệnh tối đa trong một khối (maxBlockExUnits)

Nhóm Kinh tế bao gồm:

  • Hệ số phí tối thiểu (minFeeA)
  • Hằng số phí tối thiểu (minFeeB)
  • Khóa ủy quyền Tiền gửi Lovelace (keyDeposit)
  • Đăng ký pool Tiền gửi Lovelace (poolDeposit)
  • Mở rộng tiền tệ (rho)
  • Mở rộng ngân quỹ (tau)
  • Cắt giảm phần thưởng cố định tối thiểu cho pool (minPoolCost)
  • Tiền gửi Lovelace tối thiểu trên mỗi byte của UTxO được đăng nhiều kỳ (coinsPerUTxOByte)
  • Giá của các đơn vị thực thi Plutus (prices)

Nhóm Kỹ thuật bao gồm:

  • Ảnh hưởng cam kết pool (a0)
  • Kỷ nguyên nghỉ hưu tối đa của pool (eMax)
  • Số lượng pool mong muốn (nOpt)
  • Các mô hình chi phí thực hiện của Plutus (costModels)
  • Số lượng đầu vào tài sản thế chấp tối đa (maxCollateralInputs)
  • Tỷ lệ tài sản thế chấp cần thiết cho tập lệnh (collateralPercentage)

Nhóm quản trị bao gồm tất cả các tham số giao thức mới được giới thiệu trong CIP này:

  • Ngưỡng bỏ phiếu quản trị ( P1, P{2a}, P{2b}, P3, P4, P5a}, P5b}, P5c}, P6, P7, Q1, Q{2b}, Q4)
  • Giới hạn nhiệm kỳ của Ủy ban hiến pháp
  • Hết hạn Đề xuất quản trị
  • Ký gửi Đề xuất quản trị (govDeposit)
  • Số tiền gửi DRep (drepDeposit)

Phiếu bầu​

Mỗi giao dịch bỏ phiếu bao gồm những điều sau đây:

  • ID Đề xuất quản trị
  • Vai trò - thành viên Ủy ban hiến pháp, DRep hoặc SPO
  • Nhân chứng chứng nhận quản trị cho vai trò
  • Anchor (như được định nghĩa ở trên) cho thông tin liên quan đến cuộc bỏ phiếu
  • Phiếu thuận/ Phiếu chống/ Phiếu trắng

Đối với SPO và DRep, số phiếu bầu được bỏ (dù là Phiếu thuận, Phiếu chống hay 'Phiếu trắng) tỷ lệ thuận với Lovelace được ủy quyền cho họ tại thời điểm hành động được kiểm tra để phê chuẩn. Đối với thành viên Ủy ban hiến pháp, mỗi thành viên có một phiếu bầu.

Cảnh báo 

Phiếu trắng không được tính trong "cổ phần bỏ phiếu có hiệu lực".

Lưu ý rằng bỏ Phiếu trắng khác hoàn toàn với vote NO (bỏ Phiếu trắng có lưu thông tin trên chuỗi, còn bỏ phiếu NO thì không lưu thônd tin trên chuỗi). Để tránh nhầm lẫn, chúng tôi sẽ chỉ sử dụng từ Bỏ phiếu trắng từ thời điểm này trở đi để chỉ một hành động bỏ phiếu trực tiếp nhưng bỏ phiếu trắng.

Nhân chứng chứng nhận quản trị sẽ kích hoạt các xác minh phù hợp trong sổ cái theo UTxOW quy tắc sổ cái hiện có (tức là kiểm tra chữ ký cho các khóa xác minh và thực thi trình xác thực với một công cụ đổi phiếu bầu cụ thể và mục đích mới của Plutus cho các tập lệnh).

Có thể bỏ phiếu nhiều lần cho mỗi Đề xuất quản trị bằng một thông tin xác thực duy nhất. Các phiếu bầu được gửi sau sẽ ghi đè mọi phiếu bầu trước đó cho cùng một chứng chỉ và vai trò. Nghĩa là, cử tri có thể thay đổi quan điểm của họ đối với bất kỳ hành động nào nếu họ chọn. Ngay sau khi một Đề xuất quản trị được phê chuẩn, bỏ phiếu kết thúc. Không có phiếu bầu nào khác được xem xét hoặc ghi lại (dù là Đồng ý, Không đồng ý hay Bỏ phiếu trắng).

Quản trị​

Khi một Đề xuất quản trị được gửi thành công tới chuỗi, tiến trình của nó sẽ được theo dõi bởi trạng thái sổ cái. Cụ thể, những điều sau đây sẽ được theo dõi:

  • ID Đề xuất quản trị
  • Epoch mà hành động hết hạn
  • Số tiền đặt cọc
  • Địa chỉ phần thưởng sẽ nhận tiền gửi khi nó được trả lại
  • Tổng số Phiếu đồng ý/ Không đồng ý/ Phiếu trắng của Ủy ban hiến pháp cho hành động này
  • Tổng số Phiếu đồng ý/ Không đồng ý/ Phiếu trắng của DReps cho hành động này
  • Tổng số Phiếu đồng ý/ Không đồng ý/ Phiếu trắng của các SPO cho hành động này

Phiếu bầu quá hạn​

Các phiếu bầu từ DReps và SPO có thể trở nên vô nghĩa sau khi chuyển sang epoch mới vì chúng có thể không được đăng ký. Do đó, tất cả các phiếu bầu chưa đăng ký đều bị hủy bỏ trước khi bất kỳ phiếu bầu mới nào được xem xét.

Thay đổi đối với snapshot cổ phần​

Do snapshot cổ phần thay đổi ở mỗi kỳ epoch, nên phải tính toán một kiểm đếm mới khi mỗi Đề xuất quản trị chưa được phê chuẩn được kiểm tra để phê chuẩn. Điều này có nghĩa là một hành động có thể được ban hành ngay cả khi phiếu bầu DRep hoặc SPO không thay đổi (vì ủy quyền bỏ phiếu có thể đã thay đổi).

Các định nghĩa liên quan đến cổ phần biểu quyết​

Chúng tôi xác định một số thuật ngữ mới liên quan đến cổ phần biểu quyết:

  • Lovelace có trong đầu ra giao dịch được coi là sẵn sàng để bỏ phiếu nếu:
    • Nó chứa một chứng chỉ cổ phần đã đăng ký.
    • Chứng chỉ cổ phần đã đăng ký đã ủy quyền quyền biểu quyết của nó cho một DRep đã đăng ký.
  • Liên quan đến một tỷ lệ phần trăm P nào đó, ngưỡng bỏ phiếu DRep (SPO) đã được đáp ứng nếu tổng cổ phần tương đối đã được ủy quyền cho DRep (SPO) bỏ phiếu Đồng ý cho một Đề xuất quản trị trừ đi tổng cổ phần tương đối có đã được ủy quyền cho DReps (SPO) bỏ phiếu Không đồng ý cho Đề xuất quản trị ít nhất là P.

Ghi chú

Có một số định nghĩa thay thế cho "tổng số cổ phần đang lưu hành":

  1. Tổng tài khoản UTxO và phần thưởng.
  2. Tổng của UTxO, tài khoản phần thưởng, tiền phí và tiền gửi.
  3. Tổng nguồn cung ADA (tức là 45 tỷ ADA) trừ đi lượng dự trữ [^3].

Hiện tại, chúng tôi để ngỏ lựa chọn này để thảo luận.

Cơ sở lý luận​

Vai trò của Ủy ban hiến pháp​

Thoạt nhìn, Ủy ban hiến pháp có vẻ như là một Ủy ban đặc biệt đã được trao thêm quyền lực đối với DReps. Tuy nhiên, vì DReps có thể thay thế Ủy ban hiến pháp bất cứ lúc nào và các phiếu bầu của DRep cũng được yêu cầu để phê chuẩn mọi Đề xuất quản trị, nên Ủy ban hiến pháp không có nhiều hơn (và trên thực tế, có thể có ít quyền lực hơn DReps). Vậy Ủy ban đóng vai trò gì, và tại sao nó không thừa? Câu trả lời là Ủy ban giải quyết vấn đề bắt đầu một khuôn khổ quản trị mới. Thật vậy, ngay sau khi chúng tôi kích hoạt và cho phép khuôn khổ này hoạt động trên chuỗi, thì nếu không có Ủy ban hiến pháp, sẽ nhanh chóng cần có đủ DRep, để hệ thống không chỉ dựa vào các phiếu bầu của SPO. Chúng tôi chưa thể dự đoán mức độ tích cực của cộng đồng khi đăng ký làm DReps,

Do đó, Ủy ban hiến pháp ra đời để đảm bảo rằng hệ thống có thể chuyển từ trạng thái hiện tại sang quản trị phi tập trung hoàn toàn trong thời gian thích hợp. Hơn nữa, về lâu dài, Ủy ban có thể đóng vai trò cố vấn và cố vấn trong các quyết định quản trị bằng cách là một tập hợp các đại diện được bầu, những người được chú ý vì sự phán xét và hướng dẫn của họ trong các quyết định quản trị. Trên tất cả, Ủy ban được yêu cầu phải luôn tuân thủ Hiến pháp và phê chuẩn các đề xuất phù hợp với các quy định của Hiến pháp.

Cố ý bỏ qua việc xác minh danh tính​

Lưu ý rằng CIP này không đề cập đến bất kỳ loại xác thực hoặc xác minh danh tính nào đối với các thành viên của Ủy ban hiến pháp hoặc DReps.

Đây là cố ý.

Chúng tôi hy vọng rằng cộng đồng sẽ cân nhắc kỹ lưỡng việc chỉ bỏ phiếu và ủy quyền cho những DReps cung cấp thứ gì đó như DID để nhận dạng chính họ. Tuy nhiên, việc thực thi xác minh danh tính là rất khó nếu không có một số nhà tiên tri tập trung, điều mà chúng tôi coi là một bước đi sai hướng.

Giảm sức mạnh của các thực thể có lượng lớn ADA​

Các cơ chế, chẳng hạn như biểu quyết bậc hai, tồn tại để bảo vệ chống lại các thực thể có mức độ ảnh hưởng lớn. Tuy nhiên, trong một hệ thống dựa trên 1 Lovelace, 1 phiếu bầu, việc chia cổ phần thành số lượng nhỏ và hủy bỏ các biện pháp bảo vệ là điều rất dễ dàng. Nếu không có hệ thống xác minh danh tính trên chuỗi, chúng tôi không thể áp dụng bất kỳ biện pháp nào như vậy.

Stake pool phân bổ cổ phần​

Giao thức Cardano dựa trên cơ chế đồng thuận Proof-of-Stake, do đó, việc sử dụng phương pháp quản trị dựa trên cổ phần là hợp lý. Tuy nhiên, có nhiều cách có thể được sử dụng để xác định cách ghi lại việc phân bổ cổ phần giữa những người tham gia. Xin nhắc lại, các địa chỉ mạng hiện có thể chứa hai bộ thông tin xác thực: một bộ để xác định ai có thể mở khóa tiền tại một địa chỉ (còn gọi là thông tin xác thực thanh toán) và một bộ có thể được ủy quyền cho Stake pool (còn gọi là thông tin ủy quyền).

Thay vì xác định bộ thông tin đăng nhập thứ ba, thay vào đó, chúng tôi đề xuất sử dụng lại thông tin đăng nhập ủy quyền hiện có, sử dụng chứng chỉ trên chuỗi mới để xác định phân bổ cổ phần quản trị. Điều này ngụ ý rằng tập hợp DReps có thể (và có khả năng sẽ) khác với tập hợp SPO, do đó tạo ra sự cân bằng. Mặt khác, điều đó có nghĩa là việc phân bổ cổ phần quản trị gặp phải những thiếu sót giống như đối với sản xuất khối: ví dụ: các nhà cung cấp phần mềm ví phải hỗ trợ các sơ đồ đa ủy quyền và phải tạo điều kiện thuận lợi cho việc phân chia cổ phần thành các tài khoản phụ nếu chủ sở hữu ADA muốn ủy quyền cho nhiều DRep hoặc chủ sở hữu ADA phải chia phần nắm giữ của họ theo cách thủ công nếu ví của họ không hỗ trợ điều này.

Tuy nhiên, lựa chọn này cũng hạn chế nỗ lực triển khai trong tương lai của các nhà cung cấp ví và giảm thiểu nỗ lực cần thiết để người dùng cuối tham gia vào giao thức quản trị. Cái sau là một mối quan tâm đủ quan trọng để biện minh cho quyết định. Bằng cách dựa trên cấu trúc hiện có, hệ thống vẫn quen thuộc với người dùng và khá dễ cài đặt. Điều này tối đa hóa cả cơ hội thành công và tỷ lệ tham gia vào khuôn khổ quản trị.

Tách khởi tạo hardfork khỏi các thay đổi thông số giao thức tiêu chuẩn​

Trái ngược với các bản cập nhật tham số giao thức khác, các hardfork (hay chính xác hơn là các thay đổi lớn đối với phiên bản chính của giao thức) cần được chú ý nhiều hơn. Thật vậy, trong khi các thay đổi tham số giao thức khác có thể được thực hiện mà không cần thay đổi phần mềm quan trọng, một hardfork giả định rằng phần lớn mạng đã nâng cấp node Cardano để hỗ trợ bộ tính năng mới được giới thiệu bởi bản nâng cấp. Điều này có nghĩa là thời điểm diễn ra sự kiện hardfork phải được thông báo trước cho tất cả người dùng Cardano và yêu cầu sự phối hợp giữa các nhà điều hành Stake pool, nhà cung cấp ví, nhà phát triển DApp và nhóm phát hành node.

Do đó, đề xuất này, không giống như sơ đồ Shelley, thúc đẩy việc bắt đầu hardfork như một Đề xuất quản trị độc lập, khác với các cập nhật tham số giao thức.

Mục đích của DRep​

Không có gì trong đề xuất này hạn chế SPO trở thành DRep. Tại sao chúng ta có DReps? Câu trả lời là các SPO được chọn để sản xuất khối và không phải tất cả các SPO đều muốn trở thành DRep. Người bỏ phiếu có thể chọn ủy thác phiếu bầu của họ cho DReps mà không cần xem xét liệu họ có phải là nhà sản xuất khối giỏi hay không và SPO có thể chọn đại diện cho những người nắm giữ ADA hay không.

Bảng yêu cầu phê chuẩn​

Các yêu cầu trong bảng yêu cầu phê chuẩn được giải thích ở đây. Hầu hết các Đề xuất quản trị đều có cùng một loại yêu cầu: Ủy ban hiến pháp phải đạt đủ đại biểu quy định và DReps phải đạt đủ số phiếu Đồng ý. Điều này bao gồm các hành động sau:

  • Ủy ban/đại biểu mới (trạng thái bình thường)
  • Cập nhật Hiến pháp
  • Thay đổi tham số giao thức
  • Rút tiền ngân quỹ

Đề nghị bất tín nhiệm​

Một Đề nghị bất tín nhiệm thể hiện sự thiếu tin tưởng của cộng đồng Cardano đối với Ủy ban hiến pháp hiện tại và do đó, Ủy ban hiến pháp không nên có bất kỳ tiếng nói nào đối với việc bỏ phiếu cho Đề xuất quản trị này. Trong tình huống này, các SPO và DRep sẽ được đại diện cho ý chí của cộng đồng.

Ủy ban/đại biểu mới (trạng thái bất tín nhiệm)​

Tương tự như kiến ​​nghị bất tín nhiệm, việc bầu chọn một Ủy ban hiến pháp phụ thuộc vào cả SPO và DRep để đại diện cho ý chí của cộng đồng.

Tính linh hoạt của Đề xuất quản trị thông tin​

Mặc dù không ràng buộc trên chuỗi, nhưng Đề xuất quản trị thông tin có thể hữu ích trong một số trường hợp:

  • Phê chuẩn CIP
  • Quyết định tệp gốc cho một epoch sổ cái mới
  • Phản hồi ban đầu cho các đề xuất trong tương lai

Bắt đầu Hard-Fork​

Bất kể cơ chế quản trị nào, sự tham gia của SPO là cần thiết cho bất kỳ đợt hardfork nào vì chính họ là người phải nâng cấp phần mềm của mình. Vì lý do này, chúng tôi làm cho sự hợp tác của họ rõ ràng trong Đề xuất quản trị bắt đầu hardfork, bằng cách luôn yêu cầu phiếu bầu của họ. Ủy ban hiến pháp cũng bỏ phiếu, báo hiệu tính hợp hiến của một hardfork. DReps cũng bỏ phiếu, để đại diện cho ý chí của mọi người nắm giữ cổ phần

Cấu trúc siêu dữ liệu mới​

Cả Đề xuất quản trị và phiếu bầu đều sử dụng các trường siêu dữ liệu mới, ở dạng URL và hàm hash toàn vẹn (phản ánh cấu trúc siêu dữ liệu để đăng ký Stake pool). Siêu dữ liệu được sử dụng để cung cấp ngữ cảnh. Ví dụ, các phiếu bầu của Ủy ban hiến pháp cần có lời giải thích tại sao nó phù hợp với hiến pháp. Các Đề xuất quản trị cần giải thích lý do tại sao hành động đó là cần thiết, chuyên gia nào đã được tư vấn, v.v. Chúng tôi không muốn các ràng buộc về quy mô giao dịch giới hạn dữ liệu giải thích này, vì vậy chúng tôi sử dụng URL.

Điều này, tuy nhiên, giới thiệu các vấn đề mới. Nếu một URL không giải quyết được, kỳ vọng bỏ phiếu cho hành động đó là gì? Chúng ta có nên mong mọi người bỏ phiếu chống không?. Đây có phải là một vectơ tấn công chống lại hệ thống quản trị? Trong trường hợp như vậy, hình ảnh trước hàm hash có thể được truyền đạt theo những cách khác, nhưng chúng ta nên chuẩn bị cho tình huống này. Có nên có một bản tóm tắt về sự biện minh trên chuỗi?

Thay thế: Sử dụng siêu dữ liệu giao dịch​

Thay vì các trường chuyên dụng cụ thể trong định dạng giao dịch, chúng ta có thể sử dụng trường siêu dữ liệu giao dịch hiện có.

Siêu dữ liệu liên quan đến quản trị có thể được xác định rõ ràng bằng cách đăng ký nhãn siêu dữ liệu CIP-10. Trong đó, cấu trúc của siêu dữ liệu có thể được xác định bởi CIP này (định dạng chính xác TBD), sử dụng một chỉ mục để ánh xạ id phiếu bầu hoặc đề xuất tới URL siêu dữ liệu tương ứng và hàm hash.

Điều này tránh việc phải thêm các trường bổ sung vào nội dung giao dịch, có nguy cơ khiến người gửi dễ dàng bỏ qua hơn. Tuy nhiên, vì siêu dữ liệu được yêu cầu có thể trống (hoặc trỏ đến một URL không phân giải được), nên người gửi dễ dàng không cung cấp siêu dữ liệu và do đó, không rõ liệu điều này có làm cho tình hình trở nên tồi tệ hơn hay không.

Lưu ý rằng siêu dữ liệu giao dịch không bao giờ được lưu trữ ở trạng thái sổ cái, do đó, khách hàng sẽ phải ghép nối siêu dữ liệu với các hành động và phiếu bầu trong phương án thay thế này và sẽ không có sẵn dưới dạng truy vấn trạng thái sổ cái.

Kiểm soát số lượng các Đề xuất quản trị đang kích hoạt​

Vì các Đề xuất quản trị sẵn sẵng cho bất kỳ ai muốn đệ trình, chúng ta cần một số cơ chế để ngăn những cá nhân chịu trách nhiệm bỏ phiếu bị quá tải với hàng loạt đề xuất. Một khoản tiền đặt cọc lớn là một trong những cơ chế để ngăn các hành động như vậy. Tuy nhiên, điều này cũng trở thành rào cản đối với một số người trong việc gửi đề xuất. Tuy nhiên, xin lưu ý rằng huy động cộng đồng bằng tập lệnh Plutus luôn là một tùy chọn để thu tiền đặt cọc.

Ngoài ra, chúng ta có thể chấp nhận khả năng có một số lượng lớn các hành động hoạt động tại bất kỳ thời điểm nào và thay vào đó phụ thuộc vào xã hội hóa ngoài chuỗi để hướng sự chú ý của cử tri đến những hành động xứng đáng. Trong trường hợp này, Ủy ban hiến pháp có thể chọn chỉ xem xét các đề xuất đã thu được đủ phiếu bầu từ DReps.

Không AVST​

Bản dự thảo trước đó của CIP này bao gồm khái niệm về "ngưỡng cổ phần biểu quyết đã kích hoạt" (active voting stake threshold - AVST). Mục đích là để đảm bảo tính hợp pháp của mỗi phiếu bầu, loại bỏ khả năng, chẳng hạn như 9 trên 10 Lovelace có thể quyết định số phận của hàng triệu thực thể trên Cardano. Thực sự có hai mối quan tâm ở đây, đáng để tách biệt.

Mối quan tâm đầu tiên là khởi động hệ thống, tức là đạt đến thời điểm ban đầu khi đủ số lượng cổ phần được đăng ký để bỏ phiếu. Mối quan tâm thứ hai là hệ thống có thể mất dần sự tham gia theo thời gian. Một vấn đề với AVST là nó khuyến khích các SPO mong muốn đăng ký bỏ phiếu thấp (vì khi đó phiếu bầu của họ có trọng lượng hơn). Đây hoàn toàn không phải là một sự xem nhẹ đối với các SPO hiện có, mà là một vấn đề với các động cơ không tốt.

Do đó, chúng tôi đã chọn cách giải quyết hai mối quan tâm theo cách khác nhau. Chúng tôi giải quyết vấn đề bootstrapping như được mô tả trong phần về bootstrapping. Và chúng tôi giải quyết vấn đề tham gia dài hạn bằng cách không cho phép rút tiền thưởng (sau giai đoạn bootstrap) trừ khi cổ phần được ủy quyền cho DRep (bao gồm cả hai trường hợp đặc biệt là Bỏ phiếu trắng và 'bất tín nhiệm').

Hành trình đến việc Thực hiện​

Tiêu chí chấp nhận​

  • Epoch sổ cái mới được kích hoạt trên mạng chính Cardano, thực hiện thông số kỹ thuật trên.

Kế hoạch thực hiện​

Các tính năng trong CIP này yêu cầu một hardfork.

Tài liệu này mô tả một sự thay đổi đầy tham vọng đối với việc quản trị Cardano. Chúng tôi đề xuất thực hiện các thay đổi thông qua một hardfork.

Trong các phần tiếp theo, chúng tôi cung cấp thêm chi tiết về các hạng mục công việc triển khai khác nhau đã được xác định. Ngoài ra, phần cuối cùng đưa ra một số câu hỏi mở cần được hoàn thiện. Chúng tôi hy vọng rằng những câu hỏi đó có thể được giải quyết thông qua các hội thảo và thảo luận cộng đồng.

Phê chuẩn đề xuất này​

Việc phê chuẩn đề xuất này sẽ là một vấn đề lặp lại: chúng ta cần một số khuôn khổ quản trị để thống nhất về khuôn khổ quản trị cuối cùng nên là gì. Như đã nói nhiều lần, CIP không có thẩm quyền, cũng không phải là một cơ chế quản trị. Thay vào đó, chúng mô tả các giải pháp kỹ thuật đã được cộng đồng các chuyên gia coi là hợp lý (từ quan điểm kỹ thuật).

CIP-1694 được cho là vượt ra ngoài phạm vi thông thường của quy trình CIP và có một mong muốn mạnh mẽ là phê chuẩn CIP này thông qua một số quy trình. Tuy nhiên, quá trình đó vẫn chưa được xác định và nó vẫn là một câu hỏi mở. Quá trình cuối cùng có thể là sự kết hợp của nhiều ý tưởng khác nhau, chẳng hạn như:

  • Thu thập ý kiến ​​từ các hội thảo do cộng đồng tổ chức, chẳng hạn như hội thảo Colorado từ tháng 2 đến tháng 3 năm 2023.
  • Thực hiện các hành động bỏ phiếu trên mạng thử nghiệm công khai, với sự tham gia đầy đủ.
  • Thăm dò ý kiến ​​​​các SPO đã thành lập.
  • Tận dụng Project Catalyst để thu thập thông tin đầu vào từ cộng đồng bỏ phiếu hiện có (mặc dù nhỏ về cổ phần kích hoạt).

Thay đổi đối với nội dung các giao dịch​

  • Các yếu tố mới sẽ được thêm vào nội dung giao dịch và các khả năng cập nhật và MIR hiện tại sẽ bị xóa. Đặc biệt,

    Các Đề xuất quản trị và phiếu bầu sẽ bao gồm hai trường nội dung giao dịch mới.

  • Hai loại chứng chỉ mới sẽ được thêm vào bên cạnh những chứng chỉ hiện có:

    • Đăng ký DRep
    • Hủy đăng ký DRep
    • Đăng ký phiếu bầu

    Và tương tự, các chứng chỉ MIR và genesis hiện tại sẽ bị xóa.

  • Một mục đích mới Voting sẽ được thêm vào ngữ cảnh tập lệnh Plutus. Đặc biệt, điều này sẽ cung cấp quyền bỏ phiếu cho các tập lệnh trên chuỗi.

Cảnh báo 

Chúng tôi sẽ cung cấp thông số kỹ thuật CDDL cho từng thay đổi đó. Như thường lệ.

Thay đổi các quy tắc sổ cái hiện có​

  • Quy tắc chuyển tiếp PPUP sẽ được viết lại và chuyển ra khỏi UTxO quy tắc và đưa vào LEDGER quy tắc dưới dạng TALLY quy tắc mới.

    Nó sẽ xử lý các Đề xuất quản trị và phiếu bầu, phê chuẩn chúng và sắp xếp các Đề xuất quản trị để ban hành trong thời kỳ hiện tại hoặc tiếp theo, nếu phù hợp.

  • Quy NEWEPOCH tắc chuyển tiếp sẽ được sửa đổi.

  • Quy MIR tắc phụ sẽ bị xóa.

  • Một quy tắc mới RATIFY để thực hiện Đề xuất quản trị giai đoạn ban hành.

  • Một quy tắc mới ENACTMENT sẽ được gọi ngay sau EPOCH quy tắc đó. Quy tắc này sẽ ban hành các Đề xuất quản trị đã được phê chuẩn trước đó.

  • Quy EPOCH tắc sẽ không còn gọi NEWPP quy tắc phụ hoặc tính toán xem số đại biểu có được đáp ứng ở trạng thái PPUP hay không.

Thay đổi đối với giao thức truy vấn trạng thái cục bộ​

Khối lượng công việc quản trị trên chuỗi lớn, nhưng khối lượng công việc ngoài chuỗi cho các công cụ và ứng dụng được cho là sẽ còn lớn hơn. Để xây dựng một hệ sinh thái quản trị hiệu quả, sổ cái sẽ phải cung cấp giao diện cho các yếu tố quản trị khác nhau.

Mặc dù phiếu bầu và đăng ký DReps (de) được hiển thị trực tiếp trong các khối và do đó, sẽ có thể truy cập được thông qua các giao thức đồng bộ hóa chuỗi cục bộ hiện có; chúng tôi sẽ cần nâng cấp giao thức truy vấn trạng thái cục bộ để cung cấp thêm thông tin chi tiết về thông tin khó suy luận hơn từ các khối (tức là những khối yêu cầu duy trì trạng thái sổ cái). Các truy vấn trạng thái mới sẽ bao gồm (ít nhất):

  • Các Đề xuất quản trị hiện đang được tổ chức để ban hành
  • Các Đề xuất quản trị được phê chuẩn, với tổng số và tỷ lệ phần trăm có cổ phần, không có cổ phần và không có cổ phần
  • Ủy ban hiến pháp hiện tại và thông báo hash hiến pháp

Giai đoạn khởi động​

Chúng ta sẽ cần phải cẩn thận trong cách chúng ta khởi động mô hình Quản trị non trẻ này. Tất cả các bên liên quan sẽ cần nhiều thời gian để tự đăng ký và làm quen với quy trình.

Các điều khoản đặc biệt sẽ được áp dụng trong giai đoạn khởi động ban đầu. Đầu tiên, trong giai đoạn bootstrap, một cuộc bỏ phiếu đủ số đại biểu từ Ủy ban hiến pháp là đủ để thay đổi các tham số giao thức. Thứ hai, trong giai đoạn bootstrap, một cuộc bỏ phiếu đại biểu từ Ủy ban hiến pháp, cùng với một cuộc bỏ phiếu SPO đầy đủ, là đủ để bắt đầu một hardfork. Không có hành động nào khác có thể thực hiện được trong giai đoạn bootstrap.

Giai đoạn bootstrap kết thúc khi xảy ra một trong hai điều sau:

  1. Một lượng cổ phần vừa đủ được ủy quyền cho DReps
  2. Một số epoch nhất định đã qua (có thể là một số tháng sau hardfork)

Biện pháp an toàn cuối cùng, sau bootstrapping​

Nhiều người đã tuyên bố rằng họ tin rằng số cử tri đi bỏ phiếu thực tế sẽ không lớn đến mức gây căng thẳng cho thông lượng của hệ thống. Chúng tôi cũng tin rằng điều này có thể xảy ra, nhưng khi giai đoạn bootstrap kết thúc, chúng tôi sẽ áp dụng một biện pháp an toàn tạm thời, cuối cùng (điều này cũng sẽ cho phép chúng tôi biện minh cho số tiền gửi DRep thấp).

Đối với các giá trị X và Y vẫn chưa được xác định, ngay sau khi giai đoạn bootstrap kết thúc, khi chúng tôi tính toán phân bổ cổ phần DReps cho sang epoch tiếp theo, chúng tôi sẽ chỉ xem xét những DReps nằm trong X-nhiều DRep hàng đầu được xếp hạng theo số tiền đặt cược hoặc những DRep đó có ít nhất Y Lovelace. Mỗi epoch, giá trị của X sẽ tăng lên và giá trị của Y sẽ giảm xuống, do đó, cuối cùng X sẽ thực sự là vô hạn và Y sẽ bằng không. Lưu ý rằng đây chỉ là một động cơ khuyến khích và không có gì thực sự ngăn bất kỳ DRep nào bỏ phiếu của họ (mặc dù nó sẽ không được tính nếu nó không đáp ứng các yêu cầu).

Nếu tại một thời điểm nào đó, cộng đồng quyết định rằng thực sự có vấn đề về tắc nghẽn, thì một hardfork có thể được ban hành để giới hạn số lượng DRep theo cách hạn chế hơn.

Con số hợp lý cho giá trị ban đầu của X có thể là 5.000-10.000. Các số hợp lý cho giá trị ban đầu của Y có thể là tổng số Lovelace chia cho giá trị ban đầu của X.

Cơ chế phải được thiết lập để nới lỏng với tốc độ loại bỏ hoàn toàn các hạn chế sau khoảng thời gian từ sáu tháng đến một năm.

Ý tưởng khác / Câu hỏi mở​

Bỏ phiếu SPO có trọng số cam kết (Pledge-weighted)​

Ngoài ra, phiếu bầu của SPO có thể được cân nhắc bởi mỗi cam kết của SPO. Điều này sẽ cung cấp một cơ chế cho phép những người có cổ phần thực sự trong trò chơi có phiếu bầu mạnh hơn. Trọng số nên được lựa chọn cẩn thận.

Tự động ủy quyền lại DReps​

Một DRep có thể tùy chọn liệt kê một chứng chỉ DRep khác trong chứng chỉ đăng ký của họ. Sau khi ngừng hoạt động, tất cả các ủy quyền của DRep sẽ tự động được chuyển sang chứng chỉ DRep đã cho. Nếu DRep đó đã ngừng hoạt động, phái đoàn sẽ được chuyển sang DRep 'Astrain'.

Không đăng ký DRep​

Do đăng ký DRep không thực hiện bất kỳ chức năng cần thiết nào, chứng chỉ cho (khử) đăng ký DRep có thể bị xóa. Điều này làm cho nền dân chủ trở nên thanh khoản hơn vì nó loại bỏ một số bộ máy quan liêu và cũng loại bỏ nhu cầu ký gửi DRep, với chi phí di chuyển Anchor là một phần của chứng chỉ đăng ký DRep vào siêu dữ liệu giao dịch.

Giảm tiền gửi cho một số hành động của Quản trị​

Khoản tiền gửi được gắn với các Đề xuất quản trị tồn tại để ngăn chặn một loạt các Đề xuất quản trị không nghiêm trọng, mỗi hành động đó sẽ cần thời gian và sự chú ý từ cộng đồng Cardano. Chúng tôi có thể giảm khoản tiền gửi này cho các đề xuất trải qua một số quy trình ngoài chuỗi đã được thống nhất. Điều này sẽ được đánh dấu trên chuỗi bằng sự chứng thực của ít nhất một thành viên Ủy ban hiến pháp. Nhược điểm của ý tưởng này là nó trao nhiều quyền lực hơn cho Ủy ban hiến pháp.

Bao gồm hàm hash của cấu hình gốc (tương lai) trong đề xuất hard-fork​

Một số hard-fork yêu cầu cấu hình genesis mới. Đây là trường hợp của các hardfork Shelley và Alonzo (nhưng không phải Allegra, Mary, Vasil hoặc Valentine), có thể là trường hợp trong tương lai. Hiện tại, đề xuất này không nêu bất cứ điều gì về cấu hình nguồn gốc như vậy: nó được coi là một thỏa thuận ngoài chuỗi. Tuy nhiên, chúng tôi có thể thực thi rằng (hàm hash của) một cấu hình gốc cụ thể cũng được nắm bắt trong một Đề xuất quản trị hard-fork.

Đổi tên DReps/trạng thái bất tín nhiệm?​

Đã nhiều lần tuyên bố rằng "DReps" như được trình bày ở đây, có thể bị nhầm lẫn với Project Catalst DReps. Tương tự như vậy, một số người đã bày tỏ sự nhầm lẫn giữa trạng thái bất tín nhiệm, chuyển động bất tín nhiệm và DReps bất tín nhiệm.

Chúng ta có thể tưởng tượng việc tìm ra những thuật ngữ tốt hơn cho những khái niệm này.

Chuyển động ngân quỹ hạn chế tỷ lệ​

Không có gì ngăn cản việc rút tiền ra khỏi ngân quỹ ngoài các phiếu bầu và ngưỡng bỏ phiếu được đề xuất. Cho rằng ngân quỹ Cardano là một thành phần khá cơ bản trong chính sách tiền tệ của nó, chúng ta có thể tưởng tượng việc thực thi (ở cấp độ giao thức) số tiền tối đa có thể bị xóa khỏi ngân quỹ trong bất kỳ khoảng thời gian nào.

Bản quyền​

CIP này được cấp phép theo CC-BY-4.0

1: Mô tả chính thức về các quy tắc hiện tại đối với các Đề xuất quản trị được đưa ra trong [Đặc tả sổ cái Shelley](https://hydra.iohk.io/job/Cardano/cardano-ledger/shelleyLedgerSpec/latest/download-by-type/doc-pdf/ledger-spec).

  • For protocol parameter changes (including hardforks), the PPUP transition rule (Figure 13) describes how protocol parameter updates are processed, and the NEWPP transition rule (Figure 43) describes how changes to protocol parameters are enacted.

  • For funds transfers, the DELEG transition rule (Figure 24) describes how MIR certificates are processed, and the MIR transition rule (Figure 55) describes how treasury and reserve movements are enacted.

    Note The capabilities of the MIR transition rule were expanded in the Alonzo ledger specification

2: Có nhiều định nghĩa khác nhau về thuật ngữ "hardfork" trong ngành công nghiệp blockchain. Các hardfork thường đề cập đến các bản cập nhật không tương thích ngược của mạng. Trong Cardano, chúng tôi chính thức hóa định nghĩa hơn một chút bằng cách gọi bất kỳ nâng cấp nào dẫn đến nhiều khối được xác thực là "hardfork" và buộc các node tuân thủ phiên bản giao thức mới, loại bỏ hiệu quả các node lỗi thời không thể xử lý nâng cấp.

3: Đây là định nghĩa được sử dụng trong "cổ phần tích cực" để ủy quyền cổ phần cho Stake pool, xem Phần 17.1, Tính toán tổng cổ phần, của Đặc tả sổ cái Shelley.

Nguồn bài viết

Picture