Mithril
  • Hướng dẫn sử dụng
    • Lời chào
    • Bắt đầu
      • Khởi động một node
      • Chạy một node Mithril Signer (SPO)
      • Chạy một mạng riêng Mithril
    • Tài liệu Dev
      • Các node mạng Mithril
        • Mithril Aggregator Node
        • Mithril Signer Node
        • Mithril Client Node
      • Tham chiếu API
  • Giới thiệu về Mithril
  • Giao thức Mithril
    • Giao thức chuyên sâu
    • Chuỗi chứng chỉ - Certificate Chain
    • Mô phỏng
  • Mạng Mithril
    • Kiến trúc
    • Mithril Aggregator
    • Mithril Signer
    • Mithril Client
  • Tài liệu hỗ trợ
    • Mithril Explorer
    • Chú thích
    • Node
Powered by GitBook
On this page
  • Thiết kế chuỗi chứng chỉ
  • Thuật toán xác minh
  • Sự cùng tồn tại của nhiều Chuỗi
  • Sự cần thiết của khả năng tương thích
  1. Giao thức Mithril

Chuỗi chứng chỉ - Certificate Chain

PreviousGiao thức chuyên sâuNextMô phỏng

Last updated 2 years ago

Giao thức Mithril có thể được tóm tắt là:

Một giao thức cho phép các bên liên quan trong mạng blockchain Proof-of-Stake ký riêng lẻ các thông điệp được tổng hợp thành một đa chữ ký, đảm bảo rằng chúng đại diện cho một phần tối thiểu trong tổng số tiền đặt cọc.

Phân phối cổ phần được sử dụng để tạo đa chữ ký không thể tin cậy "nguyên trạng" và cũng phải được ký. Thật vậy, bất kỳ ai cũng có thể tương đối dễ dàng tạo Phân phối cổ phần giả và sử dụng nó để tạo ra một chữ ký đa hợp lệ sẽ được nhúng trong Giấy chứng nhận hoàn toàn hợp lệ nhưng không chính hãng. Chứng chỉ này có thể được cung cấp bởi một nút Mithril Aggregator không trung thực và do đó có thể dẫn đến việc khôi phục ảnh chụp nhanh không chính hãng bởi một Mithril Client trung thực.

Để tránh kiểu tấn công nhật thực này, việc phân phối cổ phần được sử dụng để tạo đa chữ ký phải được chứng nhận trước. Đây là nơi diễn ra Chuỗi chứng chỉ.

Cảnh báo

Phân phối cổ phần của một kỷ nguyên được tính toán bởi các Node Cardano vào cuối kỷ nguyên này. Nó sẽ có thể sử dụng được từ đầu kỷ nguyên sau.

Một cách để xác nhận phân phối cổ phần được sử dụng để tạo đa chữ ký là xác minh rằng nó đã được ký trước đó trong một chứng chỉ trước đó. Sau đó, người ta có thể xác minh một cách đệ quy rằng chứng chỉ trước đó là hợp lệ theo cùng một cách. Quy trình này có thể được thiết kế như một Chuỗi chứng chỉ: Chuỗi chứng chỉ Mithril .

Vì nhiều chứng chỉ có thể được tạo trong cùng một kỷ nguyên epoch (tức là với cùng một phân phối cổ phần), chỉ cần liên kết với một chứng chỉ của kỷ nguyên trước là đủ: điều này sẽ cho phép thời gian xác minh nhanh hơn và nó cũng sẽ tránh tắc nghẽn mạng.

Ngoài ra, chứng chỉ ở đầu Chuỗi chứng chỉ có một vai trò đặc biệt. Đây là Giấy chứng nhận Genesis. Cách duy nhất để xác thực bản phân phối cổ phần được nhúng trong Chứng chỉ Genesis là ký nó bằng một khóa cá nhân được liên kết với một khóa công khai có sẵn rộng rãi: Khóa Genesis. Đây là những chìa khóa ký hiệu các hard fork được sử dụng trong quá trình chuyển đổi kỷ nguyên của Cardano Blockchain.

Đây là sơ đồ minh họa thiết kế Chuỗi chứng chỉ :

Trường hợp các ký hiệu sau đã được sử dụng:

  • C(p,n): Chứng chỉ lúc kích hoạt pvà kỷ nguyênn

  • FC(n): Chứng chỉ kỷ nguyên đầu tiênn

  • GC: Chứng chỉ Genesis

  • H(): hàm băm hash

  • SD(n): Phân phối cổ phần của kỷ nguyênn

  • VK(n): Khóa xác minh tại epochn

  • AVK(n): Khóa xác minh tích hợp tại thời điểm nchẳng hạn nhưAVK(n) = MKT_ROOT(SD(n) || VK(n))

  • MKT_ROOT(): Merkle-tree root

  • BEACON(p,n): Báo hiệu lúc kích hoạt pvà kỷ nguyênn

  • METADATA(p,n): Siêu dữ liệu của chứng chỉ lúc kích hoạt pvà kỷ nguyênn

  • MSG(p,n): Thông báo của chứng chỉ lúc kích hoạt pvà kỷ nguyênn

  • MULTI_SIG(p,n): Đã tạo nhiều chữ ký cho tin nhắnH(MSG(p,n) || AVK(n-1))

  • GENESIS_SIG(MSG): Chữ ký Genesis, tức là chữ ký MSGbằng các Chìa khóa Genesis

Hàm băm của một Chứng chỉ H(C(p,n)) được tính như là phép nối ( ||) của tất cả các trường của nó. Do đó, nếu một trường được sửa đổi, hàm băm của nó sẽ khác.

Thông tin được nhúng trong METADATA(p,n)trường là:

  • Phiên bản của Giao thức Mithril

  • Tham số của Giao thức Mithril ( k, mvà phi_f)

  • Ngày và giờ bắt đầu tạo nhiều chữ ký

  • Ngày và giờ chứng chỉ được niêm phong

  • Danh sách những người ký đã đóng góp tích cực cho đa chữ ký

Thông báo MSG(p,n)là một bản đồ của nhiều giá trị được liên kết với các khóa tương ứng của chúng và cung cấp một cách để thêm nhiều thông tin hơn trong chứng chỉ mà không phá vỡ chính chuỗi. Đây có thể là bất kỳ thông điệp nào mà người ký có thể tính toán một cách xác định nhờ sự đồng thuận của Cardano: ảnh chụp nhanh tệp không thể thay đổi, bộ Utxo, phân phối stahe, ...

GHI CHÚ

THÔNG TIN

Khóa xác minh tổng hợpAVK là gốc của cây Merkle nơi mỗi lá được lấp đầy. Nó đại diện cho Phân phối cổ phần tương ứng một cách cô đọng.H(STAKE(signer) || VK(signer))

Xác minh Chuỗi chứng chỉ có thể được nêu như sau:

CHAIN_VERIFY[C(p,n(p))] = CERT_VERIFY[C(p,n(p)] ^ CERT_VERIFY[FC(n(p))] ^ CERT_VERIFY[FC(n(p)-1)] ^ ... ^ CERT_VERIFY[FC(1)] ^ CERT_VERIFY[GC]

Trường hợp các ký hiệu sau đã được sử dụng:

  • Kỷ nguyên n(p)phụ thuộc vào trình kích hoạtp

  • CHAIN_VERIFY[]: Xác minh tất cả các chuỗi ngược lại từ một chứng chỉ

  • CERT_VERIFY[]: Xác minh một chứng chỉ cụ thể

Chuỗi chứng chỉ hợp lệ nếu từ một Chứng chỉ, cho đến Chứng chỉ Genesis của chuỗi có ít nhất một chứng chỉ hợp lệ cho mỗi kỷ nguyên.

Chứng chỉ không phải Genesis là hợp lệ nếu và chỉ khi được AVKsử dụng để xác minh đa chữ ký cũng là một phần của thông điệp đã ký được sử dụng để tạo đa chữ ký hợp lệ trong Chứng chỉ đã được niêm phong trước đó.

Chứng chỉ Genesis hợp lệ nếu và chỉ khi Chữ ký Genesis của nó được xác minh bằng Khoá Genesis Công khai được quảng cáo .

Việc triển khai thuật toán sẽ hoạt động như sau đối với chứng chỉ:

  • Bước 1 : Sử dụng chứng chỉ này làmcurrent_certificate

  • Bước 2 : Xác minh (hoặc không thành công) rằng current_hashcủa chứng chỉ current_certificatelà hợp lệ (bằng cách tính toán nó và so sánh với hashtrường của chứng chỉ)

  • Bước 3 : Nhận giá previous_hashtrị previous_certificatebằng cách đọc giá trị của nó trongcurrent_certificate

  • Bước 4 : Xác minh (hoặc không thành công) rằng cái multi_signaturetrong số đó current_certificatelà hợp lệ

  • Bước 5 : Truy xuất previous_certificatemã có hàm băm previous_hash:

    • Bước 5.1 : Nếu nó không phải là genesis_certificate:

      • Bước 5.1.1 : Xác minh (hoặc không thành công) rằng previous_hashcủa chứng chỉ previous_certificatelà hợp lệ (bằng cách tính toán nó và so sánh với hashtrường của chứng chỉ)

      • Bước 5.1.2 : Xác minhcurrent_avk

        • Bước 5.1.2.1 : Nếu current_certificatelà first_certificatecủa kỷ nguyên, hãy xác minh (hoặc không thành công) rằng current_avkcủa kỷ nguyên đó current_certificatelà một phần của thông báo được ký bởi chữ ký đaprevious_certificate

        • Bước 5.1.2.2 : Khác xác minh (hoặc không thành công) rằng cái current_avkcủa current_certificatecái giống với cái current_avkcủa cáiprevious_certificate

      • Bước 5.1.3 : Xác minh (hoặc không thành công) rằng cái multi_signaturetrong số đó previous_certificatelà hợp lệ

      • Bước 5.1.4 : Sử dụng previous_certificateas current_certificatevà bắt đầu lại ở Bước 2

    • Bước 5.2 : Nếu là genesis_certificate:

      • Bước 5.2.1 : Xác minh (hoặc không thành công) rằng previous_hashcủa chứng chỉ previous_certificatelà hợp lệ (bằng cách tính toán nó và so sánh với hashtrường của chứng chỉ)

      • Bước 5.2.2 : Xác minh (hoặc không thành công) rằng phần current_avktrong số đó current_certificatelà một phần của thông báo được ký bởi chữ ký ban đầu củaprevious_certificate

      • Bước 5.2.3 : Chứng chỉ hợp lệ (Thành công)

Điều gì sẽ xảy ra nếu một số Mithril Aggregator tuyên bố rằng không nhận được đủ chữ ký? Điều này không thực sự quan trọng, vì sẽ có một Mithril Aggregator khác sẽ thu thập đủ chữ ký và tổng hợp chúng thành một Chứng chỉ hợp lệ.

Tương tự như vậy, các Mithril Aggregators khác nhau có thể có các chế độ xem khác nhau về các chữ ký cá nhân được gửi (một trình tổng hợp có thể nhận được 10 chữ ký và một trình tổng hợp khác có thể nhận được 11), điều này sẽ dẫn đến các Chứng chỉ khác nhau ký cùng một thông báo.

Điều này sẽ dẫn đến các Chuỗi chứng chỉ khác nhau , tất cả sẽ liên kết lại với Chứng chỉ Genesis. Thật vậy, chúng sẽ được đại diện bởi một cây chứng chỉ trong đó mỗi đường đi ngang từ gốc đến lá đại diện cho một Chuỗi chứng chỉ hợp lệ.

Chuỗi chứng chỉ được thiết kế để tồn tại lâu dài. Tại một thời điểm nhất định, chúng tôi sẽ cần xử lý việc xác minh đa chữ ký từ các phiên bản kế thừa của thư viện mật mã Mithril .

Để đạt được khả năng tương thích ngược này, một số tùy chọn có sẵn:

  • Xử lý các chức năng xác minh nhiều chữ ký của các phiên bản kế thừa

  • Tạo lại Chứng chỉ Genesis theo thời gian

  • Tạo chứng chỉ cột mốc Milestones Certificates trung gian (với cả chữ ký đa và chữ ký gốc)

  • Thiết kế một thuật toán di chuyển định dạng

Trình kích hoạt đại diện cho thời điểm mà chứng chỉ sẽ được tạo. Nó được kết hợp với ít nhất kỷ nguyên liên quan để tạo của chứng chỉ. Trong triển khai hiện tại, trình kích hoạt này là một . Quá trình tạo kỷ nguyên và quá trình tạo bộ kích hoạt có thể không liên quan đến nhau.

Beacon
Số tệp bất biến mới
Thuật toán xác minh
Sự cùng tồn tại của nhiều Chuỗi
Sự cần thiết của khả năng tương thích
Thiết kế chuỗi chứng chỉ
Page cover image