💡the general design
introduce to OICP (ordinals inscriptions classification protocol) by @toshtoss
Last updated
introduce to OICP (ordinals inscriptions classification protocol) by @toshtoss
Last updated
This article explores an interesting experiment on how to define collections more accurately on ordinals ecosystem. We will introduce a new protocol called OICP (Ordinals Inscriptions Classification Protocol). If widely accepted, this protocol will bring about significant changes in the way we define and distribute tokens above ordinals ecosystem. Now, let's discuss some of the key features of this new protocol.
The finalization processes for almost all protocols in ordinals ecosystem currently rely on the indexers provided by third-party platforms. While these platforms may compete and eventually reach consensus, it is still undesirable for the behavior of a protocol to be determined solely by third-party indexers. In other words, these protocols itself is not play the role as the only source of trust.
Therefore, the primary issue that the OICP protocol aims to address is ensuring that the protocol itself defines observable outcomes to ensure trust. In other words, if anyone repeats the execution of the protocol according to its specifications, they should obtain the same results, and these results must be regarded as the only trusted facts.
Polymorphism is a commonly used term in computer programming that refers to the concept of an entity belonging to multiple types. Now, let's apply this concept to the context of the ordinals ecosystem, where any given inscription can belong to multiple collections, and each collection can include inscriptions of different categories and attributes. For example, an inscription in the Bitcoin Punk collection can simultaneously belong to the Bitcoin Punk collection itself, the <100k collection, and even a small portion of the <10k or <1k collection. It is important to emphasize that in this case, the many-to-many relationship between inscriptions and collections creates an ecosystem that is significantly different from the NFT ecosystem on Ethereum, where an NFT can only belong to a single contract. Actually, this many-to-many relationship perfectly captures the essence of Bitcoin's genes. I may delve deeper into this topic in a separate article in the future.
Currently, major markets like Magic Eden, Unisats, and Ordinals Wallet do adopted polymorphism to classify inscriptions. However, the privilege of defining polymorphic collections solely belongs to large platforms, which is unfair and goes against the spirit of blockchain. This article will introduce the OICP protocol, which allows the definition of such polymorphic collections through on-chain declarations, empowering everyone to define them fairly.
Intelligent conditions refer to the protocol's ability to define verifiable and complex filtering criteria to determine which actions are permissible within the protocol. I carefully considered the chapter title to avoid overwhelming readers with excessive concepts related to smart contracts on Ethereum. However, it is undeniable that defining tokens/collections and ensuring fair distribution are the most crucial functionalities in the current cryptographic ecosystem. These functionalities represent essential features that a comprehensive protocol should support. In this article, we will introduce the OICP protocol, which provides support for this functionality in a completely different manner from Ethereum. An example will be presented to demonstrate in what extent this feature can ensure fair distribution.
Firstly, OICP is not a standalone protocol; it needs to be integrated with existing protocols such as BRC-20 and BRC-1115 to be effectively utilized. The relationship between OICP and these protocols is akin to that of HTTP and SSL, where their combination gives rise to a more secure protocol, HTTPS. To provide a clearer understanding of this concept, it is necessary to briefly introduce the protocol stack of the Ordinal ecosystem, which will help us grasp the position of the OICP protocol within the overall architecture. Since I haven't come across any comprehensive articles systematically discussing the Ordinals' protocol stack, I have created a sketch to illustrate the interrelationships between these protocols.
Transfer layer
The transport layer is primarily responsible for ensuring the reliable movement of objects from one address to another. The Ordinals protocol serves as a representative protocol at this layer. It defines a set of rules for ordering and tracking the movement of sats within the Bitcoin network from the perspective of an external observer, without altering the Bitcoin protocol itself. In this way, it implements the logic of the transport layer.
This layer of protocol can be compared to defining an envelope within the Bitcoin network, where upper-layer protocols can place stuff inside and have it sent to any address.
Intermedia layer
The primary purpose of the intermediate layer is to establish a connection between the data of upper-layer protocols and the underlying transmission medium. The Inscription protocol serves as a typical representative of this layer. It defines an inactive branch using Taproot scripts and utilizes bytecode as a separator to create a space which can be used by upper-layer protocol to store data. Additionally, it establishes a set of rules to determine how this data space is associated with sats.
This protocol layer can be seen as a piece of A4 paper and it is placed inside an envelope. Upper-layer protocols can record any data on this paper, such as images, text, and so on.
Entity layer
The primary objective of the entity layer is to describe an entity by defining a set of parseable attributes. Protocols like BRC-20 and BRC-1115 operate within this layer. For example, the BRC-20 protocol utilizes the JSON format to define a token entity and specifying attributes such as the token's name, quantity, and limits.
This layer of protocols can be likened to defining entities on an A4 paper using standard tables. These entities can have multiple properties and can be use to represent objects such as humans, animals, as well as actions such as minting or running.
Cluster layer
Finally, we reach the Cluster layer, where the OICP protocol resides. The primary purpose of this layer is to classify the various entities defined in the entity layer by establishing a set of intelligent filter conditions. In other words, this layer enables us to define collections and determine which actions are allowed and which are not.
Based on the above discussion, the main objective of OICP has gradually become clear, which is to filter out clusters of entities that meet certain criteria from a vast amount of inscriptions based on the properties defined by entity layer.
The purpose of a layered protocol is to horizontally separate the concerns of a problem domain. This means that the upper-layer protocol inherits all behaviors from the lower-layer protocol by default. Additionally, the upper layer has the capability to override certain behaviors if necessary. We will give an example to illustrate this.
In order to achieve the defined objectives of the protocol, this section will explore the selection of an appropriate language to define the filtering criteria. The chosen language should meet several key requirements. Firstly, it should enable precise and unambiguous definition of the filtering conditions, ensuring determinism and consistently producing the same results when applied to identical input data. Secondly, It should align with established industry standards and be compatible with the technical stack commonly used by developers. Lastly, it should have mature tools available, enabling even individuals without any programming experience to execute and verify the output. After careful consideration, it becomes evident that SQL (Structured Query Language) emerges as the optimal choice for fulfilling these requirements.
In this chapter, we will define the data structure used by the OICP protocol. The dataset is designed as a Minimum Viable Product (MVP) to reduce the cost for validators to create and maintain this data model. In fact, this data model is a subset of the popular Dune.com data model. The purpose of this choice is to allow more people to quickly verify the execution results using Dune. However, it should be noted that this does not imply any binding relationship between the protocol and Dune, as both are derived from the abstraction of the Bitcoin UTXO model.
CREATE TABLE inputs (
tx_id VARBINARY, -- the txn that spent this utxo
index INTEGER, -- the position of this input within a transaction
value DOUBLE, -- utxo value
block_height BIGINT, -- the block contain this input
witness_data ARRAY(VARBINARY) -- witness_data, where store the inscription data
) CREATE TABLE outputs (
tx_id VARBINARY, -- the txn that create this utxo
index BIGINT, -- the position of this output within a transaction
value DOUBLE, -- utxo value
block_height BIGINT, -- the block contain this output
address VARCHAR(255) -- target address
);CREATE TABLE transaction (
tx_id VARBINARY, -- the hash of this transaction
block_height BIGINT, -- the block contain this txn
index BIGINT -- the position of this transaction within a block
);Basically, the relationship of these tables can be represented as the following E-R chart. I suppose the comments and this diagram is good enough to explain data structure.
In analogy, things gather in categories, while people dwell in communities. In this layer, we classify entities and define collections.
