CoinExVietNam
Active Member
- 345
- 7
Giới thiệu
Tất cả chúng ta đều quen thuộc với mã thông báo, NFT và các tiêu chuẩn mã thông báo cổ điển, chẳng hạn như ERC-20 và ERC-721, dựa trên chúng. Cụ thể, ERC-20 được thiết kế cho các mã thông báo có thể thay thế được, trong khi ERC-721 đại diện cho một tiêu chuẩn cho các mã thông báo không thể thay thế và phù hợp với các tác phẩm nghệ thuật hoặc tài sản quý hiếm. Điều đó cho thấy, những mã thông báo này được triển khai như thế nào? Làm thế nào chúng có thể được áp dụng cho các ứng dụng liên quan?
Hôm nay, chúng ta sẽ xem xét các nguyên tắc, phạm vi áp dụng và xu hướng tương lai của các hợp đồng mã thông báo này, bao gồm các tiêu chuẩn mã thông báo bao gồm ERC-20, ERC-721, ERC-1155 và ERC-3525 được hoàn thiện gần đây.
(Các mã liên quan đến ERC-20, ERC-721 và ERC-1155 là từ OpenZeppelin và mã thông báo ERC-3525 là từ Solv Protocol)
Hash Table
Trước khi đi vào nguyên tắc của hợp đồng mã thông báo, trước tiên chúng ta phải giải quyết một khái niệm quan trọng: hash table. Nói một cách đơn giản, hash table là một cấu trúc dữ liệu để cho phép chúng ta nhanh chóng tìm ra các giá trị dựa trên các khóa. Hợp đồng mã thông báo sử dụng hash table để lưu trữ thông tin về tài sản và người được ủy quyền. Để biết thêm thông tin cụ thể về hash table, vui lòng tham khảo tại: https://en.wikipedia.org/wiki/Hash_table
Băm dữ liệu & Chức năng
Token tiến hành băm dữ liệu theo nhiều cách khác nhau. Phương pháp băm dữ liệu xác định các chức năng của mã thông báo và có thể được coi là cách nội dung được cấu trúc và ghi lại. Tùy thuộc vào mục đích cụ thể, băm dữ liệu có thể được chia thành tài khoản chung và tài khoản cá nhân. Tài khoản chung ghi lại trạng thái tài sản tổng thể của mã thông báo (loại, số lượng và ủy quyền) và cũng chứa cài đặt của những người/quản trị viên được ủy quyền (những người được ủy quyền có thể tự do chuyển nhượng/ủy quyền lại tài sản của chủ sở hữu tài sản).
Trong ngữ cảnh này, các chức năng đề cập đến thiết kế dựa trên mã thông báo của băm dữ liệu và các chức năng có thể đạt được của mã thông báo (tức là các chức năng công khai), bao gồm truy vấn & truyền, đúc và ghi nội dung.
Trong các đoạn dưới đây, chúng tôi sẽ xem xét các tiêu chuẩn mã thông báo khác nhau về chức năng và hàm băm dữ liệu của chúng.
ERC-20
1. Băm dữ liệu
Tài khoản chung: ERC-20 quản lý và ghi lại tài sản mã thông báo tổng thể thông qua bảng băm: Sắp xếp (địa chỉ => uint256). Cụ thể, Khóa là địa chỉ người dùng và Giá trị được sắp xếp là một số nguyên dương được sử dụng để ghi lại số lượng mã thông báo thuộc sở hữu của mỗi địa chỉ.
[TBODY]
[/TBODY]Tài khoản cá nhân: Nhờ sự đơn giản của riêng nó, ERC-20 có thể ghi lại tất cả các tài sản chỉ bằng một bảng băm. Như vậy, chỉ cần một bảng để đăng ký những người được ủy quyền của tài khoản cá nhân. Bảng này sử dụng một địa chỉ duy nhất làm khóa để sắp xếp tới một bảng khác nhắm mục tiêu các khóa là số nguyên dương:
Ví dụ: 0x1 là tài khoản Mã thông báo A và có thể ủy quyền cho các tài khoản khác (ví dụ: 0x2, 0x3) sử dụng mã thông báo thay mặt cho nó. Cần lưu ý rằng giới hạn số tiền của các tài khoản được ủy quyền đó chỉ hợp lệ khi được đặt bởi tài khoản chứa mã thông báo (trong trường hợp này là 0x1).
[TBODY]
[/TBODY]2. Chức năng (cơ bản)
[TBODY]
[/TBODY] ERC-20 cung cấp gần như tất cả các điều kiện cần thiết để lưu thông và để mã thông báo được sử dụng làm vốn chủ sở hữu và hàng hóa. Thêm vào đó, tiêu chuẩn này cũng cho phép dễ sử dụng.
ERC-721
1. Băm dữ liệu
Tài khoản chung:
[TBODY]
[/TBODY]Bảng sắp xếp các số nguyên dương tới các địa chỉ. Ở đây, ID là khóa và địa chỉ là giá trị. Ngoài ra, mỗi ID chỉ tương ứng với một địa chỉ, điều này đạt được tính duy nhất và độ hiếm theo yêu cầu của NFT.
Tài khoản cá nhân:
So với ERC-20, ghi lại số dư tài sản của tất cả các địa chỉ bằng cách sử dụng một bảng, ERC-721 thêm một bảng thứ hai chứa các bản ghi tài sản của các tài khoản cá nhân. Trong bảng này, địa chỉ riêng lẻ là khóa và số lượng NFT được giữ bởi các địa chỉ là giá trị. Nó ghi lại tổng số NFT đang nắm giữ của mỗi địa chỉ. Tuy nhiên, bảng không ghi lại ID cụ thể của các NFT do các tài khoản cá nhân nắm giữ và ID chỉ có thể nhận được thông qua các truy vấn sự kiện.
[TBODY]
[/TBODY]Về mặt ủy quyền của những người được ủy quyền, với mã thông báo ERC-721, một tài khoản cá nhân đi kèm với một người được ủy quyền tổng thể và địa chỉ được ủy quyền này có thể vận hành tất cả các mã thông báo hợp đồng có trong tài khoản Sắp xếp (địa chỉ => (Sắp xếp (địa chỉ => bool)). Chỉ tài khoản cá nhân mới có thể cấp phép như vậy.
[TBODY]
[/TBODY]Mặt khác, NFT có ID cũng có thể được ủy quyền độc lập: Sắp xếp (uint256 => địa chỉ), và người được ủy quyền có thể vận hành NFT tương ứng. Trong trường hợp này, cả chủ sở hữu NFT và người được ủy quyền tổng thể đều có thể cấp ủy quyền đó.
[TBODY]
[/TBODY]Nhìn chung, một địa chỉ cá nhân có thể có số lượng người được ủy quyền không giới hạn, tất cả những người này đều có thể thay đổi những người được ủy quyền về ID của địa chỉ cá nhân. Mặt khác, một ID cá nhân chỉ có thể có một người/địa chỉ được ủy quyền.
Ví dụ: 0x1 sở hữu ba NFT trong một chuỗi NFT tương ứng với ba ID: 1, 2 và 3. Trong trường hợp này, 0x1 cấp quyền liên quan đến NFT cho vô số địa chỉ riêng lẻ. Nếu nó cho phép 0x2, thì 0x2 sẽ có thể chuyển ba NFT. Trong khi đó, 0x2 cũng có thể cấp quyền chuyển ID (ví dụ: 1) sang một địa chỉ khác như 0x3. Tại thời điểm này, 0x3 có thể truyền NFT tương ứng với ID theo bất kỳ cách nào mà anh ta thấy phù hợp.
2. Chức năng
[TBODY]
[/TBODY]ERC-721 đảm bảo tính độc nhất và hiếm có của các tác phẩm nghệ thuật kỹ thuật số bằng cách đảm bảo rằng một id chỉ tương ứng với một tác phẩm nghệ thuật mà chỉ có thể được sở hữu bởi một địa chỉ. Ngoài ra, các nhà sưu tập cũng có thể thu thập nhiều ID của cùng một chuỗi và kiểm tra số lượng NFT mà họ sở hữu. Tuy nhiên, hợp đồng ERC-721 không hỗ trợ truy vấn ID của tất cả các NFT được nắm giữ bởi một địa chỉ, đây là một tính năng có thể là một hạn chế do tiêu thụ khí đốt. Ví dụ: 0x1 chứa hai NFT của cùng một chuỗi. Mặc dù chúng ta có thể biết rằng địa chỉ chứa hai NFT thông qua chức năng hợp đồng, nhưng chúng ta không thể xác định các NFT cụ thể mà nó nắm giữ. Để chúng tôi xác định ID cụ thể của hai NFT, chúng tôi phải sử dụng nhật ký / sự kiện của hợp đồng.
ERC-1155
1. Băm dữ liệu
Trong ERC-1155, cả tài khoản tổng thể và tài khoản cá nhân đều được triển khai đồng thời. Với ERC-1155, mã thông báo được ghi lại bằng cách sử dụng Sắp xếp có địa chỉ trỏ đến Sắp xếp.
[TBODY]
[/TBODY]Ở đây, chúng tôi đã tìm thấy một sự thật thú vị: Thiết kế của ERC-1155 thực sự là một kiểu kết hợp giữa ERC-20 và ERC-721. Do đó, ERC-1155 có thể được coi là một giải pháp quản lý mã thông báo kết hợp nhiều mã thông báo dựa trên ERC20 và ERC721 (số lượng được đặt thành một và mỗi địa chỉ chỉ tương ứng với một số tiền).
Về quản lý ủy quyền, ERC-1155 không có tính năng ủy quyền cho các ID cá nhân và nó chỉ cho phép người dùng cấp quyền đầy đủ cho các tài khoản cá nhân, giúp đơn giản hóa việc quản lý ủy quyền.
[TBODY]
[/TBODY]2. Chức năng
[TBODY]
[/TBODY]Tóm lại, chúng tôi nhận thấy rằng ERC-1155 không hoàn toàn là một tiêu chuẩn mã thông báo, mà là một giải pháp quản lý mã thông báo. Hợp đồng tổng thể thậm chí không có Tên hoặc Biểu tượng. Bên cạnh đó, một ID có thể được sở hữu bởi nhiều địa chỉ cùng một lúc, điều này cho phép một ID có thể thay thế hoặc không thể thay thế. Do đó, ERC-1155 có thể được áp dụng trong các trường hợp yêu cầu nhiều loại mã thông báo. Ví dụ: trong các trò chơi blockchain, các vật phẩm bao gồm coins hoặc vật liệu không thể thay thế và vũ khí huyền thoại độc đáo đều có thể đạt được bằng cách sử dụng một hợp đồng ERC-1155. Ngoài ra, tiêu chuẩn cũng có thể được áp dụng bởi các hệ sinh thái tương đối nhỏ, chẳng hạn như hệ sinh thái LP Token của DEX.
Đồng thời, từ khi ERC-1155 đưa ra khái niệm giá trị, nếu một người chỉ có thể sở hữu một ID, một cài đặt có thể đạt được thông qua các hợp đồng trong tương lai, thì ERC-1155 có thể trở thành một phiên bản của ERC-721 có các giá trị số (tức là Semi-Fungible Token). Điều này có nghĩa là ERC-1155 làm cho các NFT có thể cập nhật được. Ví dụ: về tín dụng, tiêu chuẩn cho phép người dùng cập nhật điểm tín dụng của họ và tạo điều kiện thuận lợi cho việc thiết lập hệ thống hành vi đa tín dụng mô tả từng khía cạnh của trạng thái tín dụng của một người với một cấp số.
Mặc dù vậy, chúng tôi tin rằng ERC-1155 không phù hợp để quản lý các hệ thống mã thông báo trong các hệ sinh thái lớn vì việc quản lý ủy quyền của nó quá đơn giản: Trong ERC-1155, chỉ có ủy quyền đầy đủ; bạn không thể cấp quyền vận hành một ID, cũng như không thể đặt hạn mức tối đa. Thêm vào đó, ERC-1155 cũng không có hồ sơ tài khoản cá nhân hoàn chỉnh. Nói cách khác, bạn không thể sắp xếp tất cả các nội dung tương ứng với ID có liên quan bằng cách sử dụng địa chỉ cá nhân làm khóa và thông tin đó chỉ có sẵn thông qua nhật ký/sự kiện.
ERC-3525
Mặc dù ERC-3525 là một hợp đồng tương đối phức tạp hơn, nhưng nó cung cấp một loạt các chức năng và hồ sơ hoàn chỉnh, cũng như khả năng tùy chỉnh cao.
1. Data Hashing
Tài khoản chung: ERC-3525 đã xây dựng một cấu trúc đổi mới được gọi là TokenData, được sử dụng để mô tả một ID. Đối với những bạn không quen thuộc với mã, cấu trúc này có thể được coi là thẻ mô tả của ID có chứa ID, Slot (một đổi mới lớn của ERC-3525), số lượng mã thông báo, mọi người, người được ủy quyền (có thể chỉ là một người được ủy quyền) và địa chỉ được ủy quyền có thể chi tiêu số dư của ID.
[Broken External Image]:https://crypto4me.net/attachments/1665504796012-png.1790/?hash=2129853a1209364f05503dbc29f76f9c
Với thẻ này, chúng ta có thể ghi lại thông tin của từng ID, sau đó đặt các thẻ đó vào một danh sách gọi là _allTokens để lưu chúng.
[TBODY]
[/TBODY]Điều đó nói lên rằng một thẻ được định vị như thế nào khi chúng ta muốn kiểm tra nó? ERC-3525 sắp xếp một ID đến vị trí cấu trúc của nó trong danh sách. Ví dụ: nếu vị trí của ID 214 là 1, thì _allTokens [1] sẽ dẫn chúng ta đến thẻ mục tiêu trong danh sách. Danh sách _allTokens ghi lại trạng thái của tất cả nội dung ERC-3525.
[TBODY]
[/TBODY]Về ủy quyền ID, ERC-3525 bổ sung thêm mục tiêu là các giá trị số. Có nghĩa là, nó đánh dấu hạn ngạch tối đa theo các địa chỉ khác nhau bằng cách sử dụng ID làm khóa.
[TBODY]
[/TBODY]Tài khoản cá nhân: ERC-3525 xây dựng thẻ AddressData và bảng băm để quản lý các tài khoản cá nhân. Thẻ bao gồm danh sách các ID của các Mã được sở hữu, bảng băm về vị trí của các ID được sở hữu trong danh sách tài khoản tổng thể và bảng băm của những người được ủy quyền của tài khoản. Nói cách khác, thẻ ghi lại ID được nắm giữ bởi các tài khoản cá nhân (tất cả các ID đều được ghi lại) và những người được ủy quyền của tài khoản.
[Broken External Image]:https://crypto4me.net/attachments/1665504826398-png.1791/?hash=2129853a1209364f05503dbc29f76f9c
Sau đó, sắp xếp được sử dụng để ghi lại thông tin thẻ tương ứng (AddressData) bằng cách sử dụng địa chỉ cá nhân làm khóa.
[TBODY]
[/TBODY]Slot
Nói chung, bản ghi dữ liệu của ERC 3525 là toàn diện và được tổ chức tốt. Mặc dù vậy, cho đến nay, ngoài các bản ghi được tài liệu tốt hơn, tiêu chuẩn không khác nhiều so với ERC-1155. Điều này đưa chúng ta đến Slot, một biến được thêm vào thẻ ID. Đó là Slot làm cho ERC-3525 có khả năng tùy biến cao và cho phép các chức năng không có trong ERC-1155.
Slot cũng là một cấu trúc. Tuy nhiên, trong ERC-3525, Slots có thể tùy chỉnh. Nói cách khác, các nhà phát triển có thể thêm bất kỳ số nào và bất kỳ loại biến nào vào Slot theo nhu cầu sản phẩm cụ thể. Ví dụ: trong trường hợp trái phiếu chuyển đổi trên Solv Protocol, thông tin mà Slots có thể chứa bao gồm Ngày đáo hạn, Giá chuyển đổi và Có thể chuyển đổi. Vị trí này, kết hợp với các biến như ID (# 6800) và Số dư (2.400 USDC), cho phép các nhà phát triển tạo NFT trái phiếu chuyển đổi.
[Broken External Image]:https://crypto4me.net/attachments/1665504880548-png.1792/?hash=2129853a1209364f05503dbc29f76f9c
2. Chức năng
Từ khi ERC-3525 bao gồm các hồ sơ kế toán toàn diện, nó cung cấp một loạt các chức năng và giúp chúng ta có nhiều không gian hơn cho trí tưởng tượng. Đặc biệt, một tính năng chính của ERC-3525 là nó nhận ra việc chuyển các giá trị ID và chuyển giá trị giữa các ID thuộc sở hữu của các địa chỉ riêng lẻ, điều này mở ra nhiều khả năng hơn cho NFT.
[TBODY]
[/TBODY]Ví dụ: với việc chuyển các giá trị ID, NFT có thể cập nhật trạng thái giá trị của chính nó. Đối với các NFT tín dụng và soulbound, một ERC-721 đơn giản không hỗ trợ chuyển các giá trị sẽ không đáp ứng được tất cả các nhu cầu chức năng. Các khoản tín dụng cá nhân luôn thay đổi và ERC-3525 có thể thay đổi các giá trị liên quan để phản ánh những thay đổi trong các khoản tín dụng cá nhân. Hoặc, tính năng này cũng có thể được áp dụng cho các vị trí NFT giống như trong Uniswap V3, cho phép người dùng cập nhật kích thước của vị trí của họ một cách thuận tiện hơn. Điều đó nói rằng, ERC-1155 cũng có thể được sử dụng để đạt được chức năng này và tất cả những gì chúng ta phải làm là đặt số lượng chủ sở hữu của mỗi ID thành một địa chỉ (mặc dù đây không phải là trường hợp của cấu trúc băm dữ liệu, nó có thể đạt được sau đó), cho phép chúng tôi chuyển/cập nhật các giá trị theo ERC-1155. Hơn nữa, ERC-1155 đi kèm với một thiết kế đơn giản hơn. Thêm vào đó, nó được áp dụng nhiều hơn trong các tình huống yêu cầu nhiều loại mã thông báo.
Sự chuyển giao giá trị giữa các ID thuộc sở hữu của các tài khoản cá nhân là sự khác biệt lớn nhất giữa ERC-3525 và ERC-1155 và ERC-721 về mặt chức năng. Chức năng này có giá trị về tài chính. Ví dụ: nó có thể được áp dụng để đạt được việc chuyển đổi hai hợp với các thời hạn khác nhau hoặc chuyển đổi giữa các tài khoản tài chính khác nhau (ví dụ: từ giao ngay sang futures, giống như thiết kế của CEX). Trong các tình huống như vậy, mỗi ID được chuyển thành một tài khoản tài chính. Trong khi đó, Slot được sử dụng để ghi lại thông tin tài khoản và giá trị thể hiện số dư tài khoản. Một ví dụ khác là quản lý Phạm vi (ngoài giá trị) trong Uniswap V3. Trong trường hợp này, Phạm vi có thể được ghi lại thông qua Vị trí và khi một người dùng cá nhân muốn thay đổi Phạm vi vị trí của mình, nền tảng có thể phản hồi yêu cầu bằng cách chuyển giá trị giữa các ID.
Cũng có một số nơi không được xem xét trong tiêu chuẩn ERC-3525. Ví dụ: trong ERC-3525, tên của ID không thể được chỉnh sửa theo cách thủ công. Các tên phải bắt đầu từ số 0 và theo thứ tự tuần tự. Nói cách khác, tên ID của NFT mới trong tập hợp luôn là N + 1, với N là số NFT hiện có trong tập hợp. Đây có thể là một cách để tránh các ID chồng chéo hoặc để tạo điều kiện quản lý ID dễ dàng hơn. Hơn nữa, trong một số tiện ích mở rộng, mặc dù ERC-3525 ghi lại các Khe và sắp xếp chúng theo thứ tự, nó không hỗ trợ phân loại/truy vấn id dựa trên Slot. Theo quan điểm của chúng tôi, các phương pháp phân loại/truy vấn như vậy có thể có giá trị đối với nhiều sản phẩm và trường hợp sử dụng. Ví dụ, các sản phẩm trái phiếu có thể ghi lại thông tin của các trái phiếu khác nhau thông qua Slot trước khi phát hành. Nếu Slots được sử dụng để phân tách các trái phiếu có cùng ID đáo hạn, chúng tôi có thể xây dựng các sản phẩm quản lý/giao dịch thuận tiện và chức năng hơn. Hiện tại, chức năng này chỉ có thể đạt được bằng cách truy vấn thông tin Vị trí của các ID và sau đó xây dựng Cơ sở dữ liệu của Vị trí và ID dựa trên truy vấn này hoặc bằng cách xây dựng các sự kiện và nhật ký.
Kết luận
Tóm lại, ERC-20, ERC-721, ERC-1155 và ERC-3525 đều có các trường hợp sử dụng duy nhất và các dự án nên chọn tiêu chuẩn mã thông báo phù hợp nhất theo nhu cầu cụ thể về mã thông báo của họ. Mặc dù vậy, cần lưu ý rằng ERC-3525 mới phức tạp hơn nhiều so với cả ba hợp đồng khác. Nó không chỉ kế thừa các tính năng của các tiêu chuẩn trước mà còn giới thiệu cấu trúc dữ liệu Slot độc đáo, cho phép nó thực hiện các tác vụ mới. Ngoài ra, mặc dù ERC-3525 cung cấp nhiều chức năng hơn, nó vẫn duy trì tính trật tự của hồ sơ, điều này đánh giá chúng tôi là một sự đổi mới đáng chú ý. Điều đó nói rằng, xem xét các thông tin và hồ sơ đa dạng hơn, có thể thấy trước rằng phí khí đốt của ERC-3525 sẽ đắt và tiêu chuẩn sẽ phải chịu các cuộc tấn công lỗ hổng không xác định (sau tất cả, nó đã đứng trước thử thách của thời gian).
Tất cả chúng ta đều quen thuộc với mã thông báo, NFT và các tiêu chuẩn mã thông báo cổ điển, chẳng hạn như ERC-20 và ERC-721, dựa trên chúng. Cụ thể, ERC-20 được thiết kế cho các mã thông báo có thể thay thế được, trong khi ERC-721 đại diện cho một tiêu chuẩn cho các mã thông báo không thể thay thế và phù hợp với các tác phẩm nghệ thuật hoặc tài sản quý hiếm. Điều đó cho thấy, những mã thông báo này được triển khai như thế nào? Làm thế nào chúng có thể được áp dụng cho các ứng dụng liên quan?
Hôm nay, chúng ta sẽ xem xét các nguyên tắc, phạm vi áp dụng và xu hướng tương lai của các hợp đồng mã thông báo này, bao gồm các tiêu chuẩn mã thông báo bao gồm ERC-20, ERC-721, ERC-1155 và ERC-3525 được hoàn thiện gần đây.
(Các mã liên quan đến ERC-20, ERC-721 và ERC-1155 là từ OpenZeppelin và mã thông báo ERC-3525 là từ Solv Protocol)
Hash Table
Trước khi đi vào nguyên tắc của hợp đồng mã thông báo, trước tiên chúng ta phải giải quyết một khái niệm quan trọng: hash table. Nói một cách đơn giản, hash table là một cấu trúc dữ liệu để cho phép chúng ta nhanh chóng tìm ra các giá trị dựa trên các khóa. Hợp đồng mã thông báo sử dụng hash table để lưu trữ thông tin về tài sản và người được ủy quyền. Để biết thêm thông tin cụ thể về hash table, vui lòng tham khảo tại: https://en.wikipedia.org/wiki/Hash_table
Băm dữ liệu & Chức năng
Token tiến hành băm dữ liệu theo nhiều cách khác nhau. Phương pháp băm dữ liệu xác định các chức năng của mã thông báo và có thể được coi là cách nội dung được cấu trúc và ghi lại. Tùy thuộc vào mục đích cụ thể, băm dữ liệu có thể được chia thành tài khoản chung và tài khoản cá nhân. Tài khoản chung ghi lại trạng thái tài sản tổng thể của mã thông báo (loại, số lượng và ủy quyền) và cũng chứa cài đặt của những người/quản trị viên được ủy quyền (những người được ủy quyền có thể tự do chuyển nhượng/ủy quyền lại tài sản của chủ sở hữu tài sản).
Trong ngữ cảnh này, các chức năng đề cập đến thiết kế dựa trên mã thông báo của băm dữ liệu và các chức năng có thể đạt được của mã thông báo (tức là các chức năng công khai), bao gồm truy vấn & truyền, đúc và ghi nội dung.
Trong các đoạn dưới đây, chúng tôi sẽ xem xét các tiêu chuẩn mã thông báo khác nhau về chức năng và hàm băm dữ liệu của chúng.
ERC-20
1. Băm dữ liệu
Tài khoản chung: ERC-20 quản lý và ghi lại tài sản mã thông báo tổng thể thông qua bảng băm: Sắp xếp (địa chỉ => uint256). Cụ thể, Khóa là địa chỉ người dùng và Giá trị được sắp xếp là một số nguyên dương được sử dụng để ghi lại số lượng mã thông báo thuộc sở hữu của mỗi địa chỉ.
| Sắp xếp (địa chỉ=> uint256) | |
| Địa chỉ | Số lượng |
| 0x1... | 100 |
| 0x2... | 200 |
| ... |
Ví dụ: 0x1 là tài khoản Mã thông báo A và có thể ủy quyền cho các tài khoản khác (ví dụ: 0x2, 0x3) sử dụng mã thông báo thay mặt cho nó. Cần lưu ý rằng giới hạn số tiền của các tài khoản được ủy quyền đó chỉ hợp lệ khi được đặt bởi tài khoản chứa mã thông báo (trong trường hợp này là 0x1).
| Sắp xếp(địa chỉ => (sắp xếp(địa chỉ => uint256)) | ||
| Địa chỉ cá nhân | Địa chỉ quản trị viên | Số tiền có thể quản lý |
| 0x1 | 0x2 | 100 |
| 0x3 | 200 | |
| .... | ||
| 0x123 | .... | |
| .... | ||
| .... | ||
| 0x455 | .... | |
| ... |
| ERC20 | ||
| Hàm | Chức năng | |
| Đọc | name(), decimals(), symbol() | Xem tên, ký hiệu và số thập phân của mã thông báo |
| totalSupply() | Xem nguồn cung cấp mã thông báo | |
| balanceOf(address) | Xem các mã thông báo do một địa chỉ nắm giữ | |
| allowance(address, address) | Xem hạn mức mã thông báo tối đa được nắm giữ bởi một địa chỉ có thể được quản lý bởi một địa chỉ khác | |
| Viết | Chuyển | |
| transfer(address, uint256), transferFrom(address, address, uint256) | Chuyển bất kỳ số lượng mã thông báo nào (được thực hiện bởi người được ủy quyền/chủ sở hữu) | |
| Ủy quyền | ||
| approve(address, uint256) | Cấp ủy quyền mã thông báo cho một địa chỉ và đặt hạn mức | |
| increaseAllowance(address, uint256), decreaseAllowance(address, uint256) | Tăng/giảm số tiền mà một địa chỉ có thể quản lý |
ERC-721
1. Băm dữ liệu
Tài khoản chung:
| Sắp xếp(uint256 => địa chỉ) | |
| id | Địa chỉ |
| 1 | 0x1... |
| 2 | 0x2... |
| ... |
Tài khoản cá nhân:
So với ERC-20, ghi lại số dư tài sản của tất cả các địa chỉ bằng cách sử dụng một bảng, ERC-721 thêm một bảng thứ hai chứa các bản ghi tài sản của các tài khoản cá nhân. Trong bảng này, địa chỉ riêng lẻ là khóa và số lượng NFT được giữ bởi các địa chỉ là giá trị. Nó ghi lại tổng số NFT đang nắm giữ của mỗi địa chỉ. Tuy nhiên, bảng không ghi lại ID cụ thể của các NFT do các tài khoản cá nhân nắm giữ và ID chỉ có thể nhận được thông qua các truy vấn sự kiện.
| Sắp xếp(địa chỉ => uint256) | |
| Địa chỉ | Số lượng |
| 0x1... | 3 |
| 0x2... | 5 |
| ... |
| Sắp xếp(địa chỉ => (Sắp xếp(địa chỉ => bool)) | ||
| Địa chỉ cá nhân | Địa chỉ quản trị viên | Luôn luôn cho phép |
| 0x1 | 0x2 | TRUE |
| 0x3 | TRUE | |
| .... | ||
| 0x123 | .... | |
| .... | ||
| .... |
| Sắp xếp(uint256 => địa chỉ) | |
| id | Địa chỉ quản trị viên |
| 1 | 0x1... |
| 2 | 0x2... |
| ... |
Ví dụ: 0x1 sở hữu ba NFT trong một chuỗi NFT tương ứng với ba ID: 1, 2 và 3. Trong trường hợp này, 0x1 cấp quyền liên quan đến NFT cho vô số địa chỉ riêng lẻ. Nếu nó cho phép 0x2, thì 0x2 sẽ có thể chuyển ba NFT. Trong khi đó, 0x2 cũng có thể cấp quyền chuyển ID (ví dụ: 1) sang một địa chỉ khác như 0x3. Tại thời điểm này, 0x3 có thể truyền NFT tương ứng với ID theo bất kỳ cách nào mà anh ta thấy phù hợp.
2. Chức năng
| ERC721 | ||
| Hàm | Chức năng | |
| Đọc | name(), tokenURI(uint256), symbol() | Lấy thông tin cơ bản của mã thông báo: tên, ký hiệu, URI của nội dung NFT |
| totalSupply() | Xem tổng cung mã thông báo | |
| balanceOf(address) | Xem số lượng NFT một địa chỉ nắm giữ | |
| ownerOf(uint256) | Xem chủ sở hữu của ID | |
| supportsInterface(bytes4) | Kiểm tra xem việc nhận mã thông báo có hỗ trợ ERC-721 hay không | |
| getApproved(uint256), isApprovedForAll(address, address) | Xem địa chỉ của người được ủy quyền liên quan đến ID và kiểm tra xem một địa chỉ có phải là người được ủy quyền của địa chỉ đó hay không | |
| Viết | Chuyển | |
| transferFrom(address, address, uint256) | Chuyển ID (do người được ủy quyền/chủ sở hữu thực hiện) | |
| Uỷ quyền | ||
| setApprovalForAll(address, bool) | Cấp toàn quyền cho việc quản lý một địa chỉ cá nhân | |
| approve(address, uint256) | Cấp quyền quản lý ID |
ERC-1155
1. Băm dữ liệu
Trong ERC-1155, cả tài khoản tổng thể và tài khoản cá nhân đều được triển khai đồng thời. Với ERC-1155, mã thông báo được ghi lại bằng cách sử dụng Sắp xếp có địa chỉ trỏ đến Sắp xếp.
| Sắp xếp(uint256 => Sắp xếp(địa chỉ => uint256)) | ||
| id | Địa chỉ | Số lượng |
| 1 | 0x1 | 200 |
| 0x2 | 100 | |
| .... | ||
| 2 | .... | |
| .... | ||
| .... |
Về quản lý ủy quyền, ERC-1155 không có tính năng ủy quyền cho các ID cá nhân và nó chỉ cho phép người dùng cấp quyền đầy đủ cho các tài khoản cá nhân, giúp đơn giản hóa việc quản lý ủy quyền.
| Sắp xếp(địa chỉ => (Sắp xếp(địa chỉ => bool)) | ||
| Địa chỉ cá nhân | Địa chỉ quản trị viên | Luôn luôn cho phép |
| 0x1 | 0x2 | TRUE |
| 0x3 | TRUE | |
| .... | ||
| 0x123 | .... | |
| .... | ||
| .... |
| ERC1155 | ||
| Hàm | Chức năng | |
| Đọc | uri(uint256) | Lấy URI của ID |
| totalSupply() | Xem tổng cung mã thông báo | |
| balanceOf(address, uint256), balanceOfBatch(address[], uint256[]) | Xem số dư của một địa chỉ dưới ID, với truy vấn hàng loạt được hỗ trợ | |
| supportsInterface(bytes4) | Kiểm tra xem việc nhận mã thông báo có hỗ trợ ERC-1155 hay không | |
| isApprovedForAll(address, address) | Kiểm tra xem một địa chỉ có phải là người được ủy quyền của địa chỉ đó hay không | |
| Viết | Chuyển | |
| safeTransferFrom(address, address, uint256, uint256, bytes) | Chuyển một số ID nhất định đến một địa chỉ | |
| safeTransferFrom(address, address, uint256[], uint256[], bytes) | Một địa chỉ chuyển các mã thông báo tương ứng với nhiều ID đến một địa chỉ khác hàng loạt | |
| Uỷ quyền | ||
| setApprovalForAll(address, bool) | Cấp toàn quyền cho việc quản lý một địa chỉ cá nhân |
Đồng thời, từ khi ERC-1155 đưa ra khái niệm giá trị, nếu một người chỉ có thể sở hữu một ID, một cài đặt có thể đạt được thông qua các hợp đồng trong tương lai, thì ERC-1155 có thể trở thành một phiên bản của ERC-721 có các giá trị số (tức là Semi-Fungible Token). Điều này có nghĩa là ERC-1155 làm cho các NFT có thể cập nhật được. Ví dụ: về tín dụng, tiêu chuẩn cho phép người dùng cập nhật điểm tín dụng của họ và tạo điều kiện thuận lợi cho việc thiết lập hệ thống hành vi đa tín dụng mô tả từng khía cạnh của trạng thái tín dụng của một người với một cấp số.
Mặc dù vậy, chúng tôi tin rằng ERC-1155 không phù hợp để quản lý các hệ thống mã thông báo trong các hệ sinh thái lớn vì việc quản lý ủy quyền của nó quá đơn giản: Trong ERC-1155, chỉ có ủy quyền đầy đủ; bạn không thể cấp quyền vận hành một ID, cũng như không thể đặt hạn mức tối đa. Thêm vào đó, ERC-1155 cũng không có hồ sơ tài khoản cá nhân hoàn chỉnh. Nói cách khác, bạn không thể sắp xếp tất cả các nội dung tương ứng với ID có liên quan bằng cách sử dụng địa chỉ cá nhân làm khóa và thông tin đó chỉ có sẵn thông qua nhật ký/sự kiện.
ERC-3525
Mặc dù ERC-3525 là một hợp đồng tương đối phức tạp hơn, nhưng nó cung cấp một loạt các chức năng và hồ sơ hoàn chỉnh, cũng như khả năng tùy chỉnh cao.
1. Data Hashing
Tài khoản chung: ERC-3525 đã xây dựng một cấu trúc đổi mới được gọi là TokenData, được sử dụng để mô tả một ID. Đối với những bạn không quen thuộc với mã, cấu trúc này có thể được coi là thẻ mô tả của ID có chứa ID, Slot (một đổi mới lớn của ERC-3525), số lượng mã thông báo, mọi người, người được ủy quyền (có thể chỉ là một người được ủy quyền) và địa chỉ được ủy quyền có thể chi tiêu số dư của ID.
[Broken External Image]:https://crypto4me.net/attachments/1665504796012-png.1790/?hash=2129853a1209364f05503dbc29f76f9c
Với thẻ này, chúng ta có thể ghi lại thông tin của từng ID, sau đó đặt các thẻ đó vào một danh sách gọi là _allTokens để lưu chúng.
| _allTokens: [ TokenData, TokenData, TokenData............ ] |
| Sắp xếp(uint256 => địa chỉ) | |
| id | Vị trí |
| 123 | 0 |
| 214 | 1 |
| ... | 2 |
| Sắp xếp(uint256 => Sắp xếp(địa chỉ => uint256)) | ||
| id | Địa chỉ quản trị viên | Chuyển tối đa được phép |
| 123 | 0x1 | 200 |
| 0x2 | 300 | |
| .... | ||
| 214 | .... | |
| .... | ||
| .... |
[Broken External Image]:https://crypto4me.net/attachments/1665504826398-png.1791/?hash=2129853a1209364f05503dbc29f76f9c
Sau đó, sắp xếp được sử dụng để ghi lại thông tin thẻ tương ứng (AddressData) bằng cách sử dụng địa chỉ cá nhân làm khóa.
| Sắp xếp(địa chỉ => Địa chỉ dữ liệu) | |
| Address | Individual card |
| 0x1 | AddressData |
| 0x2 | AddressData |
Nói chung, bản ghi dữ liệu của ERC 3525 là toàn diện và được tổ chức tốt. Mặc dù vậy, cho đến nay, ngoài các bản ghi được tài liệu tốt hơn, tiêu chuẩn không khác nhiều so với ERC-1155. Điều này đưa chúng ta đến Slot, một biến được thêm vào thẻ ID. Đó là Slot làm cho ERC-3525 có khả năng tùy biến cao và cho phép các chức năng không có trong ERC-1155.
Slot cũng là một cấu trúc. Tuy nhiên, trong ERC-3525, Slots có thể tùy chỉnh. Nói cách khác, các nhà phát triển có thể thêm bất kỳ số nào và bất kỳ loại biến nào vào Slot theo nhu cầu sản phẩm cụ thể. Ví dụ: trong trường hợp trái phiếu chuyển đổi trên Solv Protocol, thông tin mà Slots có thể chứa bao gồm Ngày đáo hạn, Giá chuyển đổi và Có thể chuyển đổi. Vị trí này, kết hợp với các biến như ID (# 6800) và Số dư (2.400 USDC), cho phép các nhà phát triển tạo NFT trái phiếu chuyển đổi.
[Broken External Image]:https://crypto4me.net/attachments/1665504880548-png.1792/?hash=2129853a1209364f05503dbc29f76f9c
2. Chức năng
Từ khi ERC-3525 bao gồm các hồ sơ kế toán toàn diện, nó cung cấp một loạt các chức năng và giúp chúng ta có nhiều không gian hơn cho trí tưởng tượng. Đặc biệt, một tính năng chính của ERC-3525 là nó nhận ra việc chuyển các giá trị ID và chuyển giá trị giữa các ID thuộc sở hữu của các địa chỉ riêng lẻ, điều này mở ra nhiều khả năng hơn cho NFT.
| ERC721 | ||
| Hàm | Chức năng | |
| Đọc | name(), valueDecimals(), symbol() | Đọc tên, ký hiệu và số thập phân giá trị của bộ sưu tập |
| slotURI(uint256), tokenURI(uint256), contractURI() | Đọc URI của vị trí, URI của ID và URI của hợp đồng | |
| totalSupply() | Xem số lượng ID trong toàn bộ bộ sưu tập | |
| balanceOf(address) | Xem số lượng ID thuộc sở hữu của địa chỉ | |
| ownerOf(uint256) | Xem chủ sở hữu của ID | |
| approve(uint256, address, uint256) | Cấp quyền cho một số lượng ID nhất định cho một địa chỉ | |
| supportsInterface(bytes4) | Kiểm tra xem việc nhận mã thông báo có hỗ trợ ERC-3525 hay không | |
| getApproved(uint256), isApprovedForAll(address, address) | Xem địa chỉ của người được ủy quyền liên quan đến ID và kiểm tra xem một địa chỉ có phải là người được ủy quyền của địa chỉ đó hay không | |
| slotOf(uint256) | Xem thông tin vị trí của một ID | |
| allowance(address, address) | Kiểm tra xem một địa chỉ có thể quản lý một địa chỉ khác hay không | |
| tokenByIndex(uint256) | Xem ID theo vị trí trong mảng lưu trữ ID đó | |
| tokenOfOwnerByIndex(address, uint256) | Xem ID của một địa chỉ và tìm vị trí của mảng tương ứng với ID | |
| Viết | Chuyển | |
| transferFrom(address, address, uint256) | Chuyển toàn bộ ID đến một địa chỉ (giống như chuyển theo ERC-721) | |
| transferFrom(uint256, address, uint256) | Chuyển một giá trị nhất định của ID sang ID mới, vị trí của ID mới giống với vị trí của ID hiện có | |
| transferFrom(uint256, uint256, uint256) | Chuyển một giá trị nhất định của một ID sang một ID khác (chuyển giá trị giữa các ID) | |
| Uỷ quyền | ||
| setApprovalForAll(address, bool) | Cấp toàn quyền cho việc quản lý một địa chỉ cá nhân | |
| approve(uint256, address, uint256) | Cấp quyền quản lý một số lượng ID nhất định |
Sự chuyển giao giá trị giữa các ID thuộc sở hữu của các tài khoản cá nhân là sự khác biệt lớn nhất giữa ERC-3525 và ERC-1155 và ERC-721 về mặt chức năng. Chức năng này có giá trị về tài chính. Ví dụ: nó có thể được áp dụng để đạt được việc chuyển đổi hai hợp với các thời hạn khác nhau hoặc chuyển đổi giữa các tài khoản tài chính khác nhau (ví dụ: từ giao ngay sang futures, giống như thiết kế của CEX). Trong các tình huống như vậy, mỗi ID được chuyển thành một tài khoản tài chính. Trong khi đó, Slot được sử dụng để ghi lại thông tin tài khoản và giá trị thể hiện số dư tài khoản. Một ví dụ khác là quản lý Phạm vi (ngoài giá trị) trong Uniswap V3. Trong trường hợp này, Phạm vi có thể được ghi lại thông qua Vị trí và khi một người dùng cá nhân muốn thay đổi Phạm vi vị trí của mình, nền tảng có thể phản hồi yêu cầu bằng cách chuyển giá trị giữa các ID.
Cũng có một số nơi không được xem xét trong tiêu chuẩn ERC-3525. Ví dụ: trong ERC-3525, tên của ID không thể được chỉnh sửa theo cách thủ công. Các tên phải bắt đầu từ số 0 và theo thứ tự tuần tự. Nói cách khác, tên ID của NFT mới trong tập hợp luôn là N + 1, với N là số NFT hiện có trong tập hợp. Đây có thể là một cách để tránh các ID chồng chéo hoặc để tạo điều kiện quản lý ID dễ dàng hơn. Hơn nữa, trong một số tiện ích mở rộng, mặc dù ERC-3525 ghi lại các Khe và sắp xếp chúng theo thứ tự, nó không hỗ trợ phân loại/truy vấn id dựa trên Slot. Theo quan điểm của chúng tôi, các phương pháp phân loại/truy vấn như vậy có thể có giá trị đối với nhiều sản phẩm và trường hợp sử dụng. Ví dụ, các sản phẩm trái phiếu có thể ghi lại thông tin của các trái phiếu khác nhau thông qua Slot trước khi phát hành. Nếu Slots được sử dụng để phân tách các trái phiếu có cùng ID đáo hạn, chúng tôi có thể xây dựng các sản phẩm quản lý/giao dịch thuận tiện và chức năng hơn. Hiện tại, chức năng này chỉ có thể đạt được bằng cách truy vấn thông tin Vị trí của các ID và sau đó xây dựng Cơ sở dữ liệu của Vị trí và ID dựa trên truy vấn này hoặc bằng cách xây dựng các sự kiện và nhật ký.
Kết luận
Tóm lại, ERC-20, ERC-721, ERC-1155 và ERC-3525 đều có các trường hợp sử dụng duy nhất và các dự án nên chọn tiêu chuẩn mã thông báo phù hợp nhất theo nhu cầu cụ thể về mã thông báo của họ. Mặc dù vậy, cần lưu ý rằng ERC-3525 mới phức tạp hơn nhiều so với cả ba hợp đồng khác. Nó không chỉ kế thừa các tính năng của các tiêu chuẩn trước mà còn giới thiệu cấu trúc dữ liệu Slot độc đáo, cho phép nó thực hiện các tác vụ mới. Ngoài ra, mặc dù ERC-3525 cung cấp nhiều chức năng hơn, nó vẫn duy trì tính trật tự của hồ sơ, điều này đánh giá chúng tôi là một sự đổi mới đáng chú ý. Điều đó nói rằng, xem xét các thông tin và hồ sơ đa dạng hơn, có thể thấy trước rằng phí khí đốt của ERC-3525 sẽ đắt và tiêu chuẩn sẽ phải chịu các cuộc tấn công lỗ hổng không xác định (sau tất cả, nó đã đứng trước thử thách của thời gian).
Giới thiệu sách Trading hay
Nhật Ký Giao Dịch Thực Chiến của Phù Thủy Thị trường Tài Chính
Sách chia sẻ 05 tháng giao dịch thực tế trên thị trường tài chính, sử dụng Price Action và Mô hình Biểu đồ của Phù thủy trader Peter Brandt, người có gần 50 năm kinh nghiệm trading và đạt lợi nhuận bình quân 68% lợi nhuận mỗi năm
Bài viết liên quan
