ICRC-21: Thông điệp đồng ý Canister Call (cuộc gọi smart contract)

Số người xem bài viết (Post Views): 220

Table of Contents

Tóm tắt

Những thông điệp này dự kiến sẽ được hiển thị cho người dùng để giúp họ đưa ra quyết định thông tin về việc phê duyệt cuộc gọi Canister / ký giao dịch.

Giao thức được thiết kế sao cho có thể sử dụng tương tác (ví dụ: trong ví trên trình duyệt) hoặc phi tương tác (ví dụ: trong ví lạnh).

ICRC-21 là gì?

ICRC-21 là một giao thức mô tả việc thu thập các thông điệp chấp nhận có thể đọc được bởi con người cho các cuộc gọi Canister. Những thông điệp này được thiết kế để hiển thị cho người dùng, giúp họ đưa ra quyết định thông thái về việc có nên phê duyệt một cuộc gọi Canister hay không, hoặc có nên ký kết một giao dịch hay không.

Giao thức này được thiết kế sao cho có thể sử dụng theo cách tương tác (ví dụ: trong ví dựa trên trình duyệt) hoặc không tương tác (ví dụ: trong ví lạnh).

Thế nào là Canister và Canister Call?

Trước khi đi sâu vào ICRC-21, chúng ta cần hiểu rõ khái niệm “canister” và “canister call”. Canister là một đơn vị thực thi mã trạng thái trong Internet Computer, giống như hợp đồng thông minh trong các hệ thống blockchain khác. Canister call là việc gọi một hàm hoặc phương thức trong canister để thực hiện các tác vụ như chuyển tiền, truy vấn dữ liệu và nhiều hoạt động khác.

Thuật ngữ

wallet: dịch vụ quản lý khóa của người dùng và có thể ký giao dịch Canister thay mặt họ. Thành phần này hiển thị thông điệp đồng ý cho người dùng. Ví có thể được chia thành thành phần nóng (có kết nối với IC) và thành phần lạnh (ngoại tuyến).
relying party: dịch vụ yêu cầu chữ ký trên một cuộc gọi Canister cụ thể.
target canister: Canister mục tiêu của cuộc gọi Canister.

Tình huống hiện tại

Giao tiếp với các Canister có thể có hậu quả đáng kể. Ví dụ, một Canister có thể chuyển tiền hoặc cung cấp quyền truy cập vào thông tin nhạy cảm. Đồng thời, giao tiếp với các Canister thường là kỹ thuật và đòi hỏi sự hiểu biết sâu rộng về cài đặt Canister để đánh giá chính xác hậu quả của một cuộc gọi Canister cụ thể. Điều này làm cho việc người dùng đưa ra quyết định thông tin về việc ký một cuộc gọi Canister trở nên rất khó khăn.

Các cơ chế được mô tả trong đặc tả này giảm bớt gánh nặng kỹ thuật và giúp người dùng đưa ra quyết định thông tin trước khi ký gọi Canister.

Giả định

Wallet được người dùng tin cậy.
Relying party không được tin cậy và có thể là bất cứ kẻ xấu nào.
Target canister được người dùng tin cậy. Giao tiếp với các Canister độc hại không được bao gồm trong đặc tả này. Cụ thể, tương tác với Canister độc hại có thể tạo ra các kết quả tùy ý bất kể cách nào xin phép của người dùng đã được thu thập.

Cách ICRC-21 Hoạt Động

Giao thức ICRC-21 cung cấp một giao diện để hỗ trợ các thông điệp chấp nhận cho cuộc gọi Canister:

consent_preferences: Bao gồm ngôn ngữ ưa thích của người dùng, giống như header “Accept-Language” trong giao thức HTTP.
consent_message_request: Chứa thông tin về cuộc gọi Canister, bao gồm tên phương thức và đối số của cuộc gọi.
consent_info: Chứa thông điệp chấp nhận được mô tả bằng ngôn ngữ dễ hiểu cho người dùng. Thông điệp này chỉ chứa thông tin cần thiết và liên quan đến cuộc gọi Canister cụ thể.

Khi người dùng gọi cuộc gọi Canister, giao thức ICRC-21 sẽ trả về thông điệp chấp nhận cho họ. Người dùng sẽ xem thông điệp này và quyết định có chấp nhận hoặc từ chối cuộc gọi Canister. Khi người dùng đồng ý, cuộc gọi sẽ tiếp tục; còn nếu từ chối, cuộc gọi sẽ bị hủy.

Giao diện Thông điệp Đồng ý Cuộc gọi Canister

Giao diện sau đây phải được triển khai để hỗ trợ thông điệp đồng ý cuộc gọi Canister:

rust

type consent_preferences = record {
    // Cùng ngữ nghĩa với tiêu đề Accept-Language trong HTTP
    language: text;
};

type consent_message_request = record {
    // Tên phương thức của cuộc gọi Canister.
    method: text;
    // Đối số của cuộc gọi Canister.
    arg: blob;
    // Sở thích của người dùng liên quan đến thông điệp đồng ý được hiển thị cho người dùng cuối.
    consent_preferences: consent_preferences;
};

type consent_info = record {
    // Thông điệp đồng ý mô tả về một cách có thể đọc được về những gì cuộc gọi sẽ làm.
    // Có thể sử dụng định dạng Markdown. Không cho phép sử dụng tài nguyên bên ngoài (ví dụ: hình ảnh).
    //
    // Thông điệp phải ở ngôn ngữ được chỉ định trong consent_preferences.
    // Nếu thông điệp không có sẵn trong ngôn ngữ đã chỉ định, có thể sử dụng một ngôn ngữ dự phòng.
    // Ngôn ngữ của thông điệp phải được chỉ định bằng trường ngôn ngữ.
    //
    // Thông điệp phải ngắn gọn và súc tích.
    // Nó chỉ nên chứa thông tin:
    // * liên quan đến người dùng
    // * liên quan đến đối số cuộc gọi Canister
    consent_message: text;
    // Cùng ngữ nghĩa như thuộc tính lang trong HTTP
    language: text;
};

type error_info = record {
    // Lỗi có thể xử lý bằng máy. Có thể do Canister mục tiêu chọn nhưng nên chỉ định loại lỗi.
    error_code: nat;
    // Mô tả kỹ thuật có thể đọc được về lỗi dành cho nhà phát triển, không phải người dùng cuối.
    description: text;
};

type consent_message_response = variant {
    // Cuộc gọi hợp lệ,
    valid: consent_info;
    // Cuộc gọi không được phép (ví dụ: vì cuộc gọi đến phương thức này không nên được người dùng ký, đối số vượt quá một số giới hạn, vv.)
    forbidden: error_info;
    // Cuộc gọi bị sai định dạng và sẽ gây ra lỗi (ví dụ: phương thức không tồn tại, đối số không thể giải mã, vv.).
    malformed_call: error_info;
};

service : {
    // Trả về một thông điệp đồng ý có thể đọc được cho cuộc gọi Canister đã cho.
    // Loại trả về là `opt` để cho phép mở rộng trong tương lai của biến thể consent_message_response.
    // (xem đề xuất tại đây: https://internetcomputer.org/docs/current/references/candid-ref#type-variant--n--t--)
    consent_message: (consent_message_request) -> (opt consent_message_response);
}

Ngoài việc triển khai giao diện trên, cũng được đề xuất rằng Canister cũng cung cấp giao diện candid đầy đủ của nó trong phần dữ liệu metadata candid:service công khai, như được thảo luận ở đây. Điều này cần thiết để giải mã đúng các đối số nếu ví cũng muốn hiển thị thông tin kỹ thuật về cuộc gọi Canister.

Các tình huống sử dụng

Cuộc gọi Canister được thiết kế để sử dụng cả ví lạnh và nóng. Ngoài các trường hợp sử dụng của ví, nó cũng có thể được sử dụng để tăng cường tài liệu về các giao diện canister chung.

Tình huống sử dụng ví nóng

Phần này mô tả các tương tác giữa ví và relying party cho các ví nóng:

Relying party kết nối với ví và yêu cầu chữ ký trên một cuộc gọi Canister.
Ví lấy thông điệp đồng ý từ Canister mục tiêu và xác minh phản hồi:
- consent_message_request.method phải khớp với phương thức cuộc gọi Canister.
- consent_message_request.arg phải khớp với đối số cuộc gọi Canister.
- Cuộc gọi consent_message phải được thực hiện đến Canister mục tiêu.
- Phản hồi từ cuộc gọi consent_message (được lấy bằng cách sử dụng read_state) phải được chuyển đến trong chứng chỉ hợp lệ (xem phần Chứng nhận).
- Phản hồi giải mã không được null và phải khớp với biến thể consent_message_response.valid.
Thông điệp đồng ý được hiển thị cho người dùng.
Sự đồng ý của người dùng:
- Nếu người dùng phê duyệt cuộc gọi Canister, tiếp tục với bước 5.
- Nếu người dùng từ chối cuộc gọi Canister (hoặc không phản hồi trong khoảng thời gian nhất định), ví trả về lỗi cho relying party. Không thực hiện các bước tiếp theo.
Yêu cầu được ký, gửi đến IC.
Phản hồi chứng nhận được lấy bằng cách sử dụng các yêu cầu trạng thái đọc.
Một thông điệp nên được hiển thị cho người dùng cho biết liệu cuộc gọi Canister đã thành công hay chưa.
Phản hồi được trả về cho relying party.

Tình huống sử dụng ví lạnh Phần này mô tả các tương tác giữa ví và relying party cho các ví có thành phần lạnh:

Thành phần ví lạnh không thể tương tác với Canister.
Thành phần ví lạnh không biết về thời gian.

Relying party kết nối với ví và yêu cầu chữ ký trên một cuộc gọi Canister.
Ví lấy thông điệp đồng ý từ Canister mục tiêu:
- Cuộc gọi Canister và yêu cầu thông điệp đồng ý cũng như phản hồi được chuyển đến thành phần ví lạnh.
- Thành phần ví lạnh xác minh thông điệp đồng ý:
  - Yêu cầu thông điệp đồng ý phải khớp với cuộc gọi Canister:
    - consent_message_request.method phải khớp với phương thức cuộc gọi Canister.
    - consent_message_request.arg phải khớp với đối số cuộc gọi Canister.
    - consent_message_request.canister_id phải khớp với id của Canister mục tiêu.
  - Phản hồi thông điệp đồng ý phải được chứng nhận và hợp lệ:
    - Phản hồi từ cuộc gọi consent_message phải được cung cấp trong một chứng chỉ hợp lệ (xem phần Chứng nhận).
    - Phản hồi giải mã không được null và phải khớp với biến thể consent_message_response.valid.
    - Chứng chỉ thời gian phản hồi thông điệp đồng ý phải gần đây đối với ingress_expiry của cuộc gọi Canister.
    - Sở thích người dùng của thông điệp đồng ý phải khớp với sở thích của người dùng trong ví. Cụ thể, thông điệp đồng ý phải ở một ngôn ngữ mà người dùng hiểu.
- Nếu xác minh thành công, thông điệp đồng ý được hiển thị cho người dùng.
- Nếu không, ví phải hủy quá trình ký và hiển thị thông báo lỗi cho người dùng. Không thực hiện các bước tiếp theo.
Sự đồng ý của người dùng:
- Nếu người dùng phê duyệt cuộc gọi Canister, tiếp tục với bước 7.
- Nếu người dùng từ chối cuộc gọi Canister (hoặc không phản hồi trong khoảng thời gian nhất định), ví trả về lỗi cho relying party (qua thành phần kết nối chuỗi). Không thực hiện các bước tiếp theo.
Yêu cầu được ký và chuyển đến thành phần kết nối chuỗi.
Yêu cầu được gửi đến IC.
Phản hồi chứng nhận được lấy bằng cách sử dụng các yêu cầu trạng thái đọc.
Một thông điệp nên được hiển thị cho người dùng cho biết liệu cuộc gọi Canister đã thành công hay chưa.
Phản hồi được trả về cho relying party.

Ví dụ

Dưới đây là một ví dụ không chuẩn về cách giao diện thông điệp đồng ý cuộc gọi Canister có thể được sử dụng cho phương thức chuyển tiền của sổ cái.

Yêu cầu Thông điệp Đồng ý

Đối số cho cuộc gọi Canister sổ cái để chuyển tiền:

rust

(
  record {
    to = blob "ed2182...";
    fee = record { e8s = 10_000 : nat64 };
    memo = 123 : nat64;
    from_subaccount = null;
    created_at_time = null;
    amount = record { e8s = 789_123_000 : nat64 };
  },
)

Đối số cho cuộc gọi Canister sổ cái để thông điệp đồng ý:

rust

(
   record {
      method = "transfer";
      arg = blob "4449..."; // đối số đã mã hóa bằng candid
      consent_preferences = record {
        language = "en-US"
      }
   }
)

Phản hồi Thông điệp Đồng ý

rust

(
   variant {
      valid = record {
         consent_text = "Chuyển 7.89 ICP đến tài khoản ed2182..., bao gồm ghi chú: 123. Phí: 0.0001 ICP.";
         language = "en-US"
      }
   }
)

Kết: ICRC-21 là một giao thức quan trọng giúp người dùng có khả năng đưa ra quyết định thông thái trước khi thực hiện các cuộc gọi Canister trên nền tảng Internet Computer. Với việc giảm bớt gánh nặng kỹ thuật và tăng tính minh bạch, ICRC-21 mang lại lợi ích đáng kể cho cả người dùng và hệ thống. Tuy vậy, việc áp dụng giao thức này cần được cân nhắc kỹ lưỡng để đảm bảo rằng việc thực hiện cuộc gọi Canister vẫn đảm bảo tính an toàn và hiệu quả.

Danh sách các tiêu chuẩn ICRC khác: ICRC-1, ICRC-2, ICRC-3

Click Digital

If you’d like to invest in blockchain advertising companies, just BUY token Saigon (SGN) at Pancakeswap: https://t.co/KJbk71cFe8 (do not worry about low liquidity)
Backed by Click Digital Company
Enhancing blockchain knowledge
BSC address: 0xa29c5da6673fd66e96065f44da94e351a3e2af65
Twitter: https://twitter.com/SaigonSGN135
Staking SGN: http://135web.net