Author: Techub Exclusive Interpretation

Written by: Tia, Techub News

"Bitcoin needs true programmability, not chaos."

Currently, the asset standards within the Bitcoin ecosystem are highly fragmented, with protocols like BRC-20, Ordinals, and Runes operating independently and lacking interoperability. This situation forces users and wallet developers to deal with complex formats and execution models.

Moreover, due to the UTXO model of Bitcoin's unlocking scripts and scripts to be unlocked, there is a lack of a global state and Turing-complete programming environment like Ethereum. These protocols often rely on off-chain indexers to maintain state. For instance, the BRC-20, which was spawned by the Ordinals protocol utilizing SegWit and Taproot to permanently store information without exceeding size limits, still requires complete reliance on off-chain indexers to maintain the global state of token balances. This increases operational costs and trust risks. The design intention behind Goldinals, launched by Nubit, is precisely to address these pain points.

Goldinals is a trust-minimized fungible token standard on Bitcoin, aimed at solving the current lack of standardization in the Bitcoin asset ecosystem while maintaining Bitcoin's decentralization and security. Through innovative technology and design, Goldinals provides Bitcoin users and developers with an efficient and flexible token management method. To achieve this goal, it has made significant innovations in technical and functional design, with the core requirement being to build a zkOracle for Bitcoin and verify it through BitVM.

On June 5, 2024, Nubit, the development protocol behind Goldinals, completed an $8 million seed round of financing, led by Polychain Capital, with participation from Nomad Capital, Spartan Group, L2IV, Big Brain Holdings, GCR, Protagonist, Gate Ventures, Animoca, Mask Network, and others. This latest round of financing brings Nubit’s total funding to $12 million.

The Issues of Ordinals, BRC-20, Runes, and Their Lack of Interoperability

Ordinals

Ordinals allows users to engrave arbitrary data (such as text, images, or other metadata) onto a minimal unit of Bitcoin (satoshis, abbreviated as sats) by utilizing SegWit and Taproot.

BRC-20

BRC-20 is a stateless Bitcoin token standard used to implement token minting, transfer, and burning functions. Unlike Ethereum's ERC-20, BRC-20 is not embedded in the blockchain logic but is realized as an "external" token standard through the data storage capabilities of Ordinals. The token operations of BRC-20 (such as minting and transferring) are performed through the Ordinals protocol, engraving state information in the form of JSON files into Bitcoin transactions. These JSON data define the token's name, supply, and holder's address.

Furthermore, BRC-20 does not rely on the blockchain's global state like Ethereum's ERC-20; instead, it requires off-chain indexers to scan all relevant transactions and reconstruct the current state of the tokens. For example, to query the token balance of a certain address, the indexer needs to read all historical transactions and calculate the balance.

Runes

Runes is a Bitcoin token protocol similar to BRC-20, with the core idea of embedding the token's state and operations into Bitcoin transactions, maintaining the token state by analyzing Bitcoin's UTXO (unspent transaction output) model. Runes utilize the OP_RETURN field or other standard fields of Bitcoin transactions to record token transfer and operation information. Each Rune token operation is completed through regular Bitcoin transactions.

Interoperability Issues

The implementation methods of the above protocols differ. Ordinals uses a data format embedded in Bitcoin transactions to store information, BRC-20 uses JSON format to define token states, while Runes rely more on Bitcoin's UTXO model. These formats are incompatible with each other, leading to data stored in one protocol being unable to be directly recognized and parsed by another protocol.

Additionally, BRC-20 is a stateless implementation, with all token states relying on external indexers for reconstruction, while Runes' states are directly stored on the blockchain through the UTXO model, and Ordinals focuses on marking individual satoshis. These mechanisms cannot share a unified state management approach.

Different protocols define their own token formats and rules, making direct interaction or mutual support for interoperability impossible.

Goldinals addresses the interoperability dilemma by introducing a new standard compatible with Ordinals/Runes/BRC-20 that does not require off-chain indexers to maintain state.

Core Design and Technical Implementation of Goldinals

The core functions of Goldinals include:

• Deploy: Initialize protocol parameters and create new token instances.

• Mint: Mint new tokens and allocate them to specified addresses.

• Transfer: Transfer tokens between addresses.

• Burn: Destroy tokens and reduce supply.

Although similar to ERC-20 and BRC-20, the implementation of Goldinals is more complex due to Bitcoin's stateless design and Turing-incomplete scripting language. Unlike Ethereum's seamless atomic calls, Goldinals requires careful management of state updates and validations across multiple steps to ensure all operations inherit Bitcoin's security.

Goldinals State Machine and Specific State Update Process

The Goldinals state machine consists of three main phases: Prepare, Kickoff, and Challenge.

Prepare Phase: Record Operation Intent

In this phase, the sender of the operation submits their intent (such as transfer or minting) through a Bitcoin transaction, embedding relevant metadata into the transaction. The sender uses Bitcoin's OP_RETURN field to record the parameters of the token operation, such as the receiving address, amount, and operation type. This transaction is recorded on Bitcoin, ensuring the transparency and immutability of the operation intent. The ZKOracle (zero-knowledge proof state machine) scans Bitcoin blocks, extracts, and records the Prepare transactions related to the Goldinals protocol, incorporating them into the global state.

Kickoff Phase: Validate and Initiate Operation

After the Prepare phase is completed, the sender needs to submit a transaction containing a zero-knowledge proof to validate the legitimacy of the operation. The sender generates a zero-knowledge proof (ZKP) off-chain, proving that their operation complies with protocol rules (such as sufficient balance and valid operation parameters). This proof is submitted to the Bitcoin network through a Kickoff transaction and verified by the ZKOracle. The successful execution of the Kickoff phase indicates that the legitimacy of the operation has been proven, but the operation has not yet been finally confirmed and must await the completion of the Challenge phase.

Challenge Phase: Review and Dispute

The Challenge phase is the core of the state machine design, aimed at providing a decentralized review mechanism to ensure the legitimacy of operations. During the challenge period, any participant (challenger) can dispute the submitted operation. For example, if the submitted zero-knowledge proof does not comply with the rules, the challenger can provide counter-evidence. The challenger interacts with the sender based on the interactive proof mechanism provided by BitVM to verify the operation. If issues are found, the challenger can submit an on-chain transaction to prevent the operation from being confirmed. If no disputes arise during the challenge period, the operation will be permanently confirmed and updated to Goldinals' global state by the ZKOracle.

Implementation Details for Transfers & Minting

Transfer

In a transfer operation, the sender first submits a Bitcoin transaction during the Prepare phase, recording the intent to transfer tokens on-chain. The ZKOracle records and verifies this transaction. In the Kickoff phase, the sender submits a zero-knowledge proof, demonstrating that their balance is sufficient and the operation complies with the rules. In the Challenge phase, challengers can verify whether the submitted proof and transaction comply with the protocol rules. If there are no challenges, the transfer is ultimately confirmed, and the balance of the receiving address is updated.

Minting

The minting process is similar to the transfer. The sender submits a transaction containing minting parameters during the Prepare phase. Then, in the Kickoff phase, the sender must provide a zero-knowledge proof to verify that the minting operation complies with the rules set by the protocol (such as supply limits and allocation restrictions). In the Challenge phase, challengers verify whether the operation meets the conditions, and if there are no disputes, the minting operation is ultimately confirmed.

Balance Query

Users can scan all Prepare transactions related to their address using the scanblocks command in Bitcoin Core and check the final state of these transactions. This method allows users to verify their balance without relying on external indexers.

Conclusion

Compared to other protocols (such as BRC-20), Goldinals has significant advantages. It eliminates reliance on external indexers, with all validations completed directly through the Bitcoin network, enhancing decentralization and freeing users from trust in third-party services. Additionally, Goldinals' transaction process is more efficient, avoiding the cumbersome requirement of multiple Bitcoin transactions to complete a single operation as seen in BRC-20, thereby significantly reducing complexity and transaction costs. Furthermore, with the introduction of zero-knowledge proofs, Goldinals possesses strong programmability, supporting multi-signature wallets, conditional transfers, and complex logic triggered by external events, broadening the protocol's applicability.

At the same time, it is crucial to note that Goldinals introduces a unified asset standard in its design, integrating the functionalities and logic of existing protocols. Nubit is also building a special compiler that converts user-friendly code into optimized scripts for Bitcoin while performing formal verification to mathematically check the integrity of each program.

Nubit co-founder Hanzhi stated, "Bitcoin needs true programmability, not chaos." With a strong foundation and standards, the Bitcoin ecosystem will transition from chaos to interoperable positive-sum innovation.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。