SPL TOKEN PROGRAM IN SOLIDITY
I. Introduction
A. Brief overview of tokenization and its importance in blockchain ecosystems
Tokenization revolutionizes asset representation and trading in digital ecosystems. It converts real-world assets into cryptographic tokens on a blockchain. The key advantages include fractional ownership, liquidity, transparency, security, interoperability, programmability, global access, and driving innovation. Tokenization opens new possibilities in asset exchange, increasing efficiency and inclusivity in the global economy, making it a critical aspect of the blockchain revolution.
B. Overview of Ethereum and Solana as leading blockchain platforms
Ethereum and Solana are prominent blockchain platforms, each with distinct features and use cases that have contributed to their widespread adoption.
Ethereum, launched in 2015, revolutionized the industry with smart contracts, enabling decentralized applications (DApps) and programmable digital assets. Its Ethereum Virtual Machine (EVM) ensures consistent and secure execution of smart contracts written in Solidity. Ethereum currently uses a Proof of Work (PoW) consensus mechanism but is transitioning to Proof of Stake (PoS) with Ethereum 2.0 for improved scalability and energy efficiency.
Solana, launched in 2020, focuses on scalability and fast transaction processing. It can handle thousands of transactions per second through its unique Proof of History (PoH) and Tower BFT (T-BFT) consensus algorithm, allowing parallel transaction processing. Solana supports multiple programming languages for smart contract development.
Ethereum boasts a mature ecosystem, featuring a wide array of DApps and DeFi protocols. In contrast, Solana's rapid growth, high throughput, and low fees are attracting developers and investors alike. Ethereum's advantage lies in its larger developer and user community, along with a more established ecosystem of dApps and services. However, Solana's appeal is undeniable, with significant investment pouring in. Choosing between Ethereum and Solana depends on individual project needs and objectives.
Ethereum remains a powerhouse for DApps and DeFi projects, while Solana excels in projects requiring fast and cost-effective transactions. Both platforms' evolution drives industry innovation and benefits stakeholders.
C. Overview of the objectives of the article
We will embark on a step-by-step guide to translate the original SPL token program, native to the Solana blockchain, into Solidity, the programming language used for Ethereum smart contract development. Through this process, Ethereum developers will gain valuable insights into tokenization strategies and smart contract implementation.
By thoroughly examining the features and capabilities of tokens on both Ethereum and Solana, we aim to highlight the differences and similarities between the two networks. This comparison will shed light on the performance, scalability, transaction costs, token standards, and other critical aspects that Ethereum developers should consider when working with tokens. Understanding these distinctions will enable developers to make informed decisions and explore potential cross-platform tokenization opportunities.
II. Understanding the SPL Token Program
A. Introduction to the SPL token program and its relevance in the Ethereum ecosystem
The SPL Token Program - this versatile Solana Program Library (SPL) implementation supports both fungible and non-fungible tokens within the Solana blockchain ecosystem. It offers efficient token creation and management capabilities.
Ethereum developers can benefit from exploring the SPL Token Program's principles, gaining valuable insights into tokenization and decentralized governance. This knowledge exchange can inspire innovative solutions for Ethereum token development and potentially foster interoperability between Ethereum and Solana tokens.
In Solana, token types are distinguished by their associated mint addresses, simplifying token creation compared to Ethereum's separate contracts for each token. This understanding broadens developers' perspectives, enabling them to explore diverse tokenization possibilities, impacting DeFi, NFTs, and token-based applications on both Ethereum and Solana.
B. Overview of the key features and functionalities of the SPL token program
The SPL Token Program is an ERC20-like token program designed for Solana, enabling creation, management, and transfer of fungible and non-fungible tokens. It seamlessly integrates with wallets and prioritizes security. Its DeFi support and smart contract capabilities empower developers. The program underwent security audits and offers comprehensive resources for developers. Let's explore some of its key components and functions:
Re-exports:
The program leverages the solana_program module through re-exports, allowing access to essential functionalities and utilities provided by the Solana blockchain.
Modules:
The SPL Token Program is structured into various modules, including:
error: Defines error types to handle potential issues during token operations.
instruction: Includes instruction types that facilitate token-related actions.
native_mint: Represents the Mint for the native token, providing essential information about the token.
processor: Implements the program state processor, managing state transitions and token operations.
state: Contains state transition types, governing how tokens can be created, managed, and transferred.
Constants:
The program defines essential constants, such as the program ID, which serves as an identifier for the SPL Token Program on the Solana blockchain.
Functions:
The SPL Token Program offers several utility functions that enhance token interactions and user experience, including:
amount_to_ui_amount: Converts a raw token amount to its user interface (UI) representation, considering the decimals field defined in its mint.
amount_to_ui_amount_string: Similar to the above, but returns the UI representation as a string.
amount_to_ui_amount_string_trimmed: Converts a raw token amount to its UI representation while trimming excess zeroes or unnecessary decimal points.
check_id: Checks if a given public key matches the program ID, ensuring secure program execution.
check_program_account: Verifies that the supplied program ID is correct for the SPL Token Program.
id: Retrieves the program ID, providing a way to identify the program.
try_ui_amount_into_amount: Attempts to convert a UI representation of a token amount back to its raw form, using the given decimals field.
ui_amount_to_amount: Converts the UI representation of a token amount back to its raw amount, using the decimals field defined in its mint.
In summary, the SPL Token Program on the Solana blockchain is a robust and versatile ERC20-like token infrastructure. Its modular design, comprehensive functions, and adherence to standards make it an ideal choice for issuing fungible and non-fungible tokens on Solana. Whether for DeFi applications, digital asset representation, or token-based governance systems, the SPL Token Program provides the necessary tools to build innovative and secure token-related solutions on the Solana blockchain.
C. Explanation of the token structure, including token accounts and minting/burning mechanisms
Creating a New Token Type
In the Solana blockchain ecosystem, new token types can be created by initializing a new Mint with the InitializeMint instruction. A Mint represents the authority to "mint" or create new tokens and is associated with each Account. Each Mint is responsible for maintaining the total supply of a specific token type, which is equal to the balances of all the associated Accounts.
It's important to note that initializing a new Mint using the InitializeMint instruction does not require the Solana account being initialized to be a signer. Both the InitializeMint instruction and the system instruction that create the Solana account should be atomically processed within the same transaction.
Once a Mint is initialized, the mint_authority is granted the ability to create new tokens using the MintTo instruction. As long as the Mint has a valid mint_authority, it is considered to have a non-fixed supply, and the mint_authority can create new tokens at any time using the MintTo instruction. However, the SetAuthority instruction can be utilized to permanently set the Mint's authority to None, thereby fixing the Mint's supply. Once the Mint's authority is set to None, no further tokens can be minted.
Additionally, token supply can be reduced at any time by issuing a Burn instruction, which removes and permanently discards tokens from an Account, effectively reducing the circulating supply of the token.
Creating Token Accounts
Accounts on the Solana blockchain hold token balances and are created using the InitializeAccount instruction. Each Account has an owner who must be present as a signer in some instructions related to the account.
The InitializeAccount instruction, like InitializeMint, does not require the Solana account being initialized to be a signer. It should also be atomically processed with the system instruction that creates the Solana account within the same transaction.
Ownership of an Account can be transferred to another user by using the SetAuthority instruction, which allows the current owner to delegate authority over the account to a new owner.
Transferring Tokens
Balances of tokens can be transferred between Accounts using the Transfer instruction. The Transfer instruction requires the owner of the source Account to be present as a signer when the source and destination accounts are different.
An essential point to remember is that when the source and destination of a Transfer are the same, the Transfer will always succeed. This means that a successful Transfer does not necessarily imply that the involved Accounts were valid SPL Token accounts, that tokens were actually moved, or that the source Account was present as a signer. Hence, developers are strongly advised to carefully check that the source and destination are different before invoking a Transfer instruction from within their program.
Burning Tokens
The Burn instruction is used to decrease an Account's token balance without transferring tokens to another Account. Essentially, burning tokens removes them from circulation permanently.
Burning tokens is akin to transferring tokens to an account with an unknown private key or destroying a private key. However, the act of burning, achieved by using Burn instructions, is more explicit and can be confirmed on the blockchain by any involved parties.
Authority Delegation
Account owners have the option to delegate authority over some or all of their token balance using the Approve instruction. Delegated authorities can then perform token transfers or burns up to the amount they have been delegated. The authority delegation can be revoked by the Account's owner through the Revoke instruction.
Multisignatures
Solana supports M of N multisignatures, which can be utilized instead of Mint authorities, Account owners, or delegates. Multisignature authorities are initialized using the InitializeMultisig instruction, where the set of N public keys are specified, and M of those N must be present as instruction signers for the authority to be considered legitimate.
Like other initializations, the InitializeMultisig instruction does not require the Solana account being initialized to be a signer. It should be atomically processed with the system instruction that creates the Solana account within the same transaction.
Freezing Accounts
A Mint can contain a freeze_authority, allowing it to issue FreezeAccount instructions that render an Account unusable. When an Account is frozen, any token instructions involving that Account will fail until it is thawed using the ThawAccount instruction. The SetAuthority instruction can be used to change a Mint's freeze_authority. If a Mint's freeze_authority is set to None, account freezing and thawing is permanently disabled, and all currently frozen accounts will remain frozen permanently.
By understanding these fundamental aspects of the token structure, including token accounts and the minting/burning mechanisms, Ethereum developers can better grasp how token development works on the Solana blockchain and make informed decisions when choosing the appropriate blockchain platform for their projects.
III. Rewriting the SPL Token Program in Solidity
A. Introduction to Solidity and its role in Ethereum smart contract development
Solidity: programming language used to create smart contracts which are executed by EVM (ethereum virtual machine). Any blockchains which are EVM compatible can execute smart contracts written in Solidity.
B. Step-by-step guide to rewriting the SPL token program in Solidity
While the SPL token program consists of both fungible and non-fungible tokens, Ethereum’s tokens are created based on different standards such as: ERC20, ERC721 (ERC stands for “Ethereum Request for Comment”, which is how standards are named on Ethereum, these standards are normally numbered). In this article, the author will demonstrate how to create ERC20 and ERC721 standard tokens.
Setting up development environments
Creating an Ethereum smart contract with Solidity doesn’t require a complex setup, you can do everything from the browser using IDEs for Solidity development, for instance Remix. It can handle almost every simple project. However, it is not recommended for projects that are more complex but you can use it as a tool to interface with your smart contracts.
On the other hand, using a framework such as Hardhat if you are experienced in JavaScript/TypeScript or Brownie if you have a background in Python is probably the best approach to follow. In this article, the author will cover the creation processes of Ethereum’s tokens using Hardhat.
Step 0: Install Dependencies(optional)
Hardhat required Nodejs and NPM on your machine to run, so if you don’t have it yet, you can find Nodejs installation here, NPM should be available once you installed Nodejs. Additionally, you also need a tool to edit your Solidity code, if you don’t have one I recommend using VSCode.
Step 1: Create development workspace
First of all, create a new folder where all your work will be located. Once you have created the folder, open a terminal at that folder and run the following command:
npx hardhat
If everything is fine, you should see something like this:
For this demonstration, the author will use JavaScript so we can select the option by pressing Enter. For the following questions, just accept the default option by pressing Enter. Once answering all questions, NPM will do the rest by installing all dependencies that are needed to the project.
For mac and linux user, if it shows this error:
Run this following command:
Step 2: Project structure
After installing dependencies, you will see the project have a structure like this:
Below is how by default Hardhat organizes newly created project, we will focus on these 4 folders/file:
contracts: the folder contains all Solidity source code.
scripts: scripts for interacting with the blockchain.
tests: includes automated tests to test your smart contracts.
hardhat.config.js: setting for hardhat.
Step 3: Installing Other Dependencies
Ethereum’s standards like ERC20 are discussed and improved by the community and one of the most well-known organizations for developing some quality standards is OpenZeppelin. We can use their contracts to help speed up the development process.
In order to install OpenZeppelin’s contracts, run this command in your terminal:
Step 4: Creating the Smart Contract
After the installation is done, we can clean our folders, removing all files from contracts, scripts and tests.
Once the folders are clean, we will create a new file called Token.sol inside the contracts folder. Fill the file with this code block:
In this codeblock, our contract is extending the ERC20 contract of OpenZeppelin by using the is keyword. In the constructor, we declare out ERC20 token’s name and symbol: “My Token” and “MYTOKEN”, then when the contract is deployed it will create a new token on the network with 1 million total supply and send all of them to the address of the deployer.
Now our token will have 6 default behaviours for people to interact with, we can add more functionality to our token such as burn token.
This function sends a number of tokens from sender address to address 0 which belongs to no one so nobody can access these tokens.
Eventually, our smart contract for ERC20 looks like this:
Step 5: Compile and deploy
Before compiling and deploying our contract, install dotenv to manage secrets inside your project:
In order to deploy contract to the blockchain, we will create a deploy.js file inside the scripts folder:
After creating the script, add this configurations to hardhat.config.js file, the configuration should includes network information as well as your deploy address’s private key or mnemonic:
In this example, the author use private key to authenticate and deploy the smart contract to the network. Create a .env at the root of the project in fill in you private key
In this demonstration, we are using BSC testnet, which is a test blockchain of Binance Smart Chain. BSC testnet is EMV compatible so our smart contract can run without any problem.
After all of that, we should be able to deploy our contract with this command:
bscTestnet is name of the network you want to deploy the contract, this name is config in hardhat.config.js
This is the expected result:
Now we can check our token on the deployed network scan:
https://testnet.bscscan.com/address/0x9F83BB3D8739b718335e3675380880a4f4cc112e
C. Documentation and Codebase on GitHub Repository
This is the codebase you can refer to: https://github.com/quanndh/erc20
D. Compare the Solidity-based SPL token program vs Solana-based SPL token program
Token Nature and Standards
Ethereum and Solana exhibit distinct approaches to token nature and standards. On Ethereum, tokens are categorized based on specific standards: ERC-20 for fungible tokens and ERC-721 for non-fungible tokens (NFTs). In contrast, Solana simplifies this classification, considering all tokens as SPL tokens, regardless of fungibility. Ethereum's ERC-721 tokens, such as NFTs, stand apart from regular tokens, while on Solana, an SPL token's uniqueness is determined by its supply limitation and associated metadata accounts.
Development Tools
Both Ethereum's Solidity and Solana's Rust support the creation of flexible token contracts. Solana, however, gains an advantage by offering a robust CLI (Command-Line Interface) tool designed specifically for developing SPL tokens. This CLI tool streamlines the token creation process, proving highly advantageous for developers. It contributes significantly to the efficiency and ease of token creation on the Solana network.
Contract Nature and Updatability
A notable distinction lies in the nature of contracts and their updatability. In Ethereum and other EVM-compatible blockchains, contracts autonomously manage state variables. In contrast, Solana programs require the creation of data accounts to hold their state variables.
Moreover, Ethereum's smart contracts, once deployed, are immutable and cannot be updated directly. To modify their functionality, developers must create proxy contracts that forward requests to the original contract. In contrast, Solana programs can be updated by an authorized entity, known as the update authority, offering greater flexibility in contract maintenance.
Token Standards on Solana
Unlike Ethereum, where precise standards (ERC-20 and ERC-721) distinguish between token types, Solana lacks such distinct classifications. On Ethereum, typical tokens adhere to the ERC-20 standard, while NFTs are ERC-721 tokens. On Solana, all tokens are treated as SPL tokens. To create an NFT on Solana, developers configure an SPL token with zero decimals, effectively designating it as a non-fungible token.
Creating Smart Contracts
While Solidity is the primary language for creating EMV-compatible smart contracts on Ethereum, Solana offers multiple avenues for developing smart contracts:
Utilizing the SPL Token CLI tool.
Writing native programs using Rust.
Exploring a recent option: using Solidity with Solang, a Solidity compiler tailored for Solana.
In conclusion, these disparities between Solidity-based SPL token programs on Ethereum and Solana-based SPL token programs underscore the unique characteristics and capabilities of each blockchain. Developers have the freedom to select the platform that aligns most closely with their specific requirements and preferences, leveraging the distinct advantages offered by either ecosystem.
IV. Comparison: Ethereum vs. Solana Token Functionality
A. Overview of token functionality on Ethereum
1. Explanation of Ethereum token standards, such as ERC-20 and ERC-721
ERC-20:
ERC-20, short for Ethereum Request for Comments 20, is a widely adopted token standard on the Ethereum blockchain. Proposed by Fabian Vogelsteller in November 2015, ERC-20 introduces a standard for Fungible Tokens. Fungible tokens are those where each unit is identical and interchangeable with another unit, meaning one token is always equal in type and value to another token. For instance, 1 ERC-20 token is equivalent to any other ERC-20 token.
The ERC-20 standard allows developers to create smart contracts that implement an API for tokens, enabling various functionalities within decentralized applications (DApps). Some of the key functionalities provided by ERC-20 include:
Transferring tokens from one account to another.
Checking the current token balance of an account.
Retrieving the total supply of the token available on the network.
Approving a specific amount of tokens from an account to be spent by a third-party account.
To be recognized as an ERC-20 Token Contract, a smart contract must implement the required methods and events outlined in the standard. These methods and events include functionalities for token transfers, balance checks, approval mechanisms, and more.
ERC-721:
ERC-721, or Ethereum Request for Comments 721, is another significant token standard on the Ethereum blockchain. It addresses the concept of Non-Fungible Tokens (NFTs). Unlike ERC-20 tokens, NFTs are unique and can have different values, often representing distinct assets, collectibles, or ownership rights.
The ERC-721 standard was proposed by William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs in January 2018. It introduces a set of methods and events that enable the creation of Non-Fungible Token Contracts within smart contracts.
Key characteristics of ERC-721 tokens include:
Uniqueness: Each ERC-721 token has a unique identifier known as tokenId, which ensures global uniqueness when paired with the contract address.
Non-Interchangeability: Unlike ERC-20 tokens, each ERC-721 token can have a different value, rarity, or visual representation, making them ideal for representing distinct and special assets.
Use Cases: ERC-721 tokens find applications in collectibles, access keys, digital assets, unique virtual items, and more.
The ERC-721 standard provides functionalities like transferring tokens between accounts, checking token ownership, and approving third-party transfers. For a smart contract to be classified as an ERC-721 Non-Fungible Token Contract, it must implement the prescribed methods and events as specified in the standard.
In summary, ERC-20 and ERC-721 are essential Ethereum token standards that serve distinct purposes. ERC-20 facilitates the creation of fungible tokens, while ERC-721 enables the creation of unique, non-fungible tokens with diverse applications in the blockchain ecosystem.
2. Comparison of Ethereum token features with the SPL token program
ERC20 Tokens on Ethereum and SPL Tokens on Solana are two different types of crypto tokens, each with its own set of features and mechanics based on the blockchain they reside on.
In summary, ERC20 Tokens and SPL Tokens have distinct characteristics based on their respective blockchains. While ERC20 Tokens are primarily fungible tokens on Ethereum, SPL Tokens on Solana encompass both fungible and non-fungible tokens. Their creation, handling, and programming languages differ, making them unique solutions for various blockchain use cases. While ERC20 Tokens have explicit standards and distinctions from other token types on Ethereum, SPL Tokens, regardless of fungibility, are collectively referred to as SPL tokens on Solana.
3. Solana vs. Ethereum NFTs: A Comparison of Non-Fungible Tokens
Non-Fungible Tokens (NFTs) have transformed the digital landscape into a virtual art gallery, revolutionizing the way we perceive and trade digital assets.
VI. Technical Differences: Ethereum and Solana
A. Performance and scalability considerations
Ethereum and Solana, two prominent blockchain platforms, differ significantly in terms of performance and scalability. Understanding these differences is vital for developers and users seeking efficient blockchain solutions.
B. Token metadata and customization options
In Ethereum, only a limited subset of token properties, such as name(), symbol(), decimals(), and totalSupply() for ERC-20 tokens, and name(), symbol(), and tokenURI() for ERC-721 tokens' optional metadata extension, are defined as methods. Similarly, ERC-1155 tokens have a method uri() in their optional metadata extension. As a result, token metadata on Ethereum lacks standardization, requiring dApps to handle each token's metadata on a case-by-case basis. This approach leads to unnecessary overhead for developers and users.
On the other hand, in Solana, the Token Metadata program offers a Metadata Account that defines numerous metadata fields associated with a token, including the collection, specified in TokenDataId in Aptos. However, the program does not provide on-chain property with mutability configuration, which limits the usability of the token standard for implementing innovative smart contract logic based on on-chain properties. An example of this limitation is observed in SFT. Instead, the Token Standard field introduced in Token Metadata v1.1.0 only acts as a container to hold customized properties. However, it is neither mutable nor on-chain, functioning as an off-chain JSON standard.
C. Token Creation and Minting
When it comes to token creation and minting, Ethereum and Solana follow distinct processes, each with its own set of steps and considerations.
D. Multisignature Support and Authority Delegation
Ethereum lacks native multisignature (multisig) support, necessitating smart contract emulation. However, the absence of a standardized API or implementation for multisig leads to varying levels of trust and potential susceptibility to bugs, requiring careful auditing. Many Ethereum multisig creators opt for bug bounty programs to enhance security.
In contrast, Solana provides authority delegation through the Approve instruction, enabling users to delegate token balance authority. Delegated authorities have transfer and burn capabilities, and the account owner can revoke delegation using the Revoke instruction.
Solana also supports M of N multisignatures as an alternative to Mint authorities or delegates. Initializing multisignature authorities involves specifying N public keys, with M required as signers for legitimacy. Notably, the InitializeMultisig instruction doesn't necessitate the initialized Solana account to be a signer. To ensure atomic processing, it's recommended to include the InitializeMultisig instruction in the same transaction as the system instruction creating the Solana account.
V. Conclusion
In conclusion, the article explored the SPL token program in Solidity and compared it with Solana's native implementation. It highlighted the significance of tokenization in blockchain ecosystems and introduced Ethereum and Solana as leading platforms.
The SPL token program's key features and functionalities within Ethereum were outlined, along with a step-by-step guide to rewriting it in Solidity. The comparison between Ethereum and Solana token functionality revealed distinct approaches to token standards and non-fungible tokens.
Technical differences, including performance, scalability, and multisignature support, were analyzed. Ethereum's mature ecosystem and security practices were contrasted with Solana's growing potential and unique features.
The choice between Ethereum and Solana depends on specific project requirements. Ethereum's established community and audited smart contract standards make it reliable, while Solana's high throughput and low fees appeal to developers seeking innovation.
Both platforms contribute significantly to tokenization, driving decentralization and transforming various industries. The comparison serves as a valuable resource for developers in making informed decisions for their tokenization needs.
VI. References
https://ethereum.org/vi/developers/docs/standards/tokens/erc-20/
https://ethereum.org/vi/developers/docs/standards/tokens/erc-721/
https://github.com/solana-labs/solana-program-library
https://soliditylang.org