Prologue: What is Veda Protocol?

The name "Veda" draws inspiration from the ancient Indian religious texts known as the Vedas, composed in Sanskrit and constituting the oldest layer of Sanskrit literature, as well as the oldest scriptures of Hinduism

In the Vedas, a profound saying resonates: "असतोमा सद्गमय" (Asato Mā Sad Gamaya), translating to “From the Darkness (of Ignorance), make me go (i.e. Lead me) towards the Light (of Spiritual Knowledge).”

Genesis of Veda: Bitcoin's Evolution

Bitcoin, as the world's first and most decentralized cryptocurrency, has undergone significant developments since its inception in 2009. Within the context of this article, two major advancements stand out: the Taproot upgrade and the Ordinals protocol. We'll delve into the history, technical details, and how they paved the way for the creation of the Veda Protocol.

I. Taproot Upgrade: Enhancing Bitcoin's Privacy and Efficiency

A. Background and Motivation

The Taproot upgrade for Bitcoin was initially proposed by Bitcoin Core developer Gregory Maxwell in 2018. Aimed at improving Bitcoin's network privacy, security, and functionality, this upgrade represents a backward-compatible soft fork.

B. Key Features and Advantages

Segregated Witness (SegWit): Introduced in 2017, SegWit laid the foundation for Taproot. It separates transaction data from witness data, enabling faster transaction times and more transactions per block.

Schnorr Signatures: Integrated into Taproot, Schnorr signatures enhance transaction efficiency and security. These signatures allow multiple signatures to be aggregated into a single signature, increasing privacy and reducing costs for complex transactions.

MAST (Merkleized Abstract Syntax Trees): Taproot utilizes a new data structure called MAST, enabling the aggregation of multiple signatures into a single signature. This enhances the privacy of complex transactions and smart contracts.

C. Activation and Impact

Taproot, activated in November 2021 with widespread support from the Bitcoin community, significantly improved Bitcoin's network privacy, security, and efficiency. It made Bitcoin more suitable for complex transactions and smart contracts.

II. Ordinals Protocol: Enabling Bitcoin NFTs

A. Background and Motivation

The development of the Ordinals protocol aims to facilitate the creation of Non-Fungible Tokens (NFTs) on the Bitcoin blockchain. Thanks to the infrastructure provided by the Taproot upgrade for storing arbitrary witness data, this became possible.

B. Key Features and Advantages

Inscriptions: Ordinals protocol allows users to inscribe arbitrary data (such as text or images) onto individual satoshis (the smallest unit of Bitcoin). These inscriptions are stored in witness data, benefiting from the separation of witness data and transaction data enabled by the Taproot upgrade.

Ordinal Theory: This theory assigns a unique number to each satoshi, allowing them to be tracked and traded as individual assets on the Bitcoin blockchain. This supports the creation of NFTs on the Bitcoin blockchain.

Compatibility with Taproot: Ordinals protocol builds upon the foundation of the Taproot upgrade, making it possible to store and transfer NFTs on the Bitcoin network without the need for a separate blockchain or token.

C. Impact and Future Prospects

The Ordinals protocol has opened up new possibilities for the Bitcoin network by supporting the creation of Non-Fungible Tokens (NFTs). This has generated significant interest within the Bitcoin ecosystem and laid the groundwork for further innovations, such as the creation of protocols like Veda.

III. Veda Protocol: Expanding the Bitcoin Ecosystem

A. Background and Motivation

Veda Protocol is an experimental EVM (Ethereum Virtual Machine) extension protocol built on top of Bitcoin Ordinals. It aims to bring smart contract functionality to the Bitcoin network, addressing the lack of first-layer smart contracts in Bitcoin.

B. Key Features and Advantages

First-Layer Smart Contracts: Veda Protocol supports the direct creation of smart contracts on the Bitcoin blockchain, making it more versatile and appealing to developers.

Compatibility with Ordinals and Taproot: Leveraging the infrastructure provided by the Taproot upgrade and Ordinals protocol, Veda Protocol seamlessly integrates with the Bitcoin network.

Enhanced Security and Efficiency: By utilizing features of the Taproot upgrade, Veda Protocol provides enhanced security and efficiency for smart contracts on the Bitcoin network.

C. Launch and Future Prospects

The emergence of the Taproot upgrade, Ordinals protocol, and Veda Protocol signifies a significant milestone in the evolution of the Bitcoin ecosystem.

These advancements expand the functionality of the Bitcoin network, making it more versatile, efficient, and secure.

As the Bitcoin ecosystem continues to grow and develop, we anticipate more innovations that will unlock the potential of the world's first and most decentralized cryptocurrency.

Apocalypse: Veda - BTC Smart Contract Extension based on Ordinals

“Veda Protocol is an EVM extension protocol based on the Ordinals theory. Users can execute EVM contract operations by creating instruction content on Ordinals (similar to Brc-20). Veda instructions are abstracted into two modules: contract deployment and contract execution.

Veda Protocol operates in two modules: Veda-core and Veda-bvm. Veda-core is responsible for protocol data verification and input, while Veda-bvm handles protocol contract execution and provides the eth_callmethod.

Veda-core primarily indexes veda instructions on Ordinals, performs a series of validations such as signature verification and instruction legality, and finally generates a transaction hash. It then encodes the address into a 20-byte hexadecimal address compatible with EVM and similar operations. The execution is triggered in Veda-bvm through JSON RPC calls with parsed data.

Veda-bvm mainly handles contract execution and contract state queries. When Veda-bvm receives an RPC call from Veda-core, it determines the operation to be taken. If it's a contract deployment instruction, it persistently stores the contract bytecode for future external RPC calls to execute read-only contract methods. Veda-bvm's virtual machine can be considered a subset of EVM, removing certain incompatible opcodes. This means developers can use existing Solidity compilers to compile bvm contracts. For specific changes, refer to the bvm modification section. Additionally, Veda-bvm provides API services for external calls to read-only contract methods.”

Let's understand the above passage like a ten years old:

“Alright, imagine you have a magical spellbook called 'Ordinals.' Now, there's a special usage of this magical book called 'Veda,' like a unique spell amplifier.

Firstly, Veda is based on this book 'Ordinals,' like adding some extra instructions to the magical book. You can perform special magical operations by writing specific instructions on the 'Ordinals' book through Veda, just like drawing on a book, but your drawings with Veda's special instructions can come to life.

This Veda magic is divided into two parts, like two superheroes. One superhero is called 'Veda-core,' acting like a magical inspector responsible for checking the instructions on the book to see if they are correct. Then, it translates these instructions into a special language that other superheroes can understand.

The other superhero is called 'Veda-bvm,' like a magical wand. When Veda-bvm hears the special language translated by Veda-core, it knows what to do. If it's a new instruction, it stores the magic for future needs. If it's an instruction to be executed immediately, like making some magic happen now, it executes it right away.

So, Veda is like a team of magical superheroes. They use a special way of casting spells on the 'Ordinals' magic book, ensuring all the magic is safe. Moreover, they can use a special language to make other superheroes understand. Pretty cool, right?”

Why EVM?

“EVM rules everything around me.”

In a profound observation on November 29, 2023, Jason Choi succinctly captures the essence of the blockchain ecosystem with the statement, "EVM rules everything around me." This concise expression emphasizes the crucial role of the Ethereum Virtual Machine (EVM) in shaping and dominating the decentralized technology domain. As the fundamental computing engine of the Ethereum blockchain, the EVM stands as a testament to the transformative power of smart contracts and decentralized applications (DApps), influencing the entire blockchain landscape. Choi's statement encapsulates the significance of the EVM in the ever-evolving field of blockchain innovation and affirms its industry-leading position.

The Ethereum Virtual Machine (EVM) is a critical component of the Ethereum blockchain. Several reasons contribute to its dominance in the blockchain ecosystem. One primary reason is that Ethereum was the first blockchain to introduce smart contracts, enabling developers to build decentralized applications (DApps) on the Ethereum network. This attracted a substantial number of developers to the platform, fostering the development of many popular DApps and tokens.

The dominance of EVM in the blockchain ecosystem is also due to network effects. As more developers and users adopt the Ethereum platform, it has become the preferred platform for many blockchain projects. This has created a virtuous cycle, where the more people use Ethereum, the more valuable and useful it becomes.

Data-wise, Ethereum has consistently been the most active blockchain for smart contracts and decentralized applications. According to data from DeFiLlama, Ethereum has the most DApps and daily active users compared to other smart contract platforms. Additionally, Ethereum has the highest market value among all smart contract platforms, and it locks in the most value in Ethereum DeFi protocols.

The dominance of EVM in the blockchain ecosystem stems from its early introduction of smart contracts, network effects, and the large and active community of developers and users.

Veda Protocol, on the other hand, represents a significant attempt to transfer the advantages of EVM to the Bitcoin ecosystem.

On the official announcement by Veda Protocol's X that the protocol is officially live after block height 822267, an anonymous developer with the encoded name UXVpcyBjdXN0b2RpZXQgaXBzb3MgY3VzdG9kZXM invoked the open-source code released by Veda on December 10th to deploy the first token based on this protocol—VEDA.

This developer, with no prior GitHub activity and a name encoded in base64, decodes to:

"Quis custodiet ipsos custodes" which translates to "Who watches the watchmen?" in Latin. This phrase, originating from the works of the Roman satirical playwright Juvenal, raises concerns about the oversight and control of power, emphasizing the need to supervise those responsible for monitoring power to prevent abuse. The choice of this phrase reflects a deep philosophical and political context.

VEDA was fully minted within approximately seven hours of deployment, and no official statements have been made by the Veda team regarding this.

The limitations in the minting process come from the contract template in the open-source portion of Veda on December 10th.

In Summary, this code is a Solidity-based ERC-20 contract.

Detailed Analysis:

1. License Declaration:

   // SPDX-License-Identifier: MIT
   

   This is an SPDX license identifier used to declare the license of the smart contract. In this case, the license is MIT, indicating that the code of this smart contract is released under the open-source MIT license.

2. Solidity Version Declaration:

   pragma solidity ^0.8.20;
   

   This statement declares the version of the Solidity compiler to be used for the contract. It specifies that the contract code should be compiled using Solidity version 0.8.20 or higher.

3. Importing ERC20 Contract:

   import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
   

   Through the import keyword, the OpenZeppelin ERC20 contract is imported. This is a generic ERC-20 contract providing standard ERC-20 functionalities.

4. Contract Definition:

   contract ERC20Token is ERC20 {
   

   Defines the ERC20Token contract, which inherits from the ERC20 contract.

5. Variable Declarations:

   uint256 public maxSupply;
   uint256 public mintAmount;
   uint8 private decimalPlaces;
   

   • maxSupply：Represents the maximum total supply of the token.

   • mintAmount：Indicates the amount of tokens minted each time.

   • decimalPlaces：Specifies the number of decimal places for the token.

6. Constructor:

   constructor(
       string memory name, 
       string memory symbol, 
       uint256 _maxSupply, 
       uint8 _decimalPlaces, 
       uint256 _mintAmount
   ) 
   ERC20(name, symbol) {
       // Constructor logic
   }
   

   The constructor is responsible for initializing various parameters of the contract. The provided parameters include the token's name, symbol, maximum supply, decimal places, and minting amount. The constructor initializes ERC20Token by calling the constructor of the inherited ERC20 contract.

7. decimals Function:

   function decimals() public view virtual override returns (uint8) {
       return decimalPlaces;
   }
   

   This function overrides the decimals function in the ERC20 contract, returning the number of decimal places for the token.

8. mint Function:

   function mint() public {
       require(tx.origin == msg.sender, "Only the original external account can call this method");
       require(totalSupply() + mintAmount <= maxSupply, "Max supply exceeded");
       _mint(msg.sender, mintAmount);
   }
   

   The mint function is used to mint new tokens. It includes the following steps:

   • Ensuring that only the original external account (tx.origin) can call this function.

   • Ensuring that the total supply after minting does not exceed the maximum supply.

   • Calling the _mint function to send the newly minted tokens to the caller (msg.sender).

Conclusion and Outlook:

So far, this appears to be the only deployed contract on the Veda Protocol.

It seems that the Veda Protocol's modifications, particularly in the Veda Protocol BVM compared to EVM, may not have been fully explored by developers, or the protocol may not yet have sufficient exposure to EVM developers.

The author earnestly hopes and calls upon the broader EVM (Ethereum Virtual Machine) developer community to engage in more experimental exploration and attempts with the Veda Protocol, echoing the sentiment expressed at the beginning:

In the Vedas, a profound saying resonates: "असतोमा सद्गमय" (Asato Mā Sad Gamaya), translating to “From the Darkness (of Ignorance), make me go (i.e. Lead me) towards the Light (of Spiritual Knowledge).”

Follow AK Labs on Twitter.