All things blockchain related, we're covering Bitcoin, Ethereum, Solana, Hashgraph, and all those good stuff
All things blockchain related, we're covering Bitcoin, Ethereum, Solana, Hashgraph, and all those good stuff
Share Dialog
Share Dialog
Subscribe to Satoshi Fan Club
Subscribe to Satoshi Fan Club
<100 subscribers
<100 subscribers
A few standup apps that use Algorand are Republic, Securitize, El Salvador’s blockchain infrastructure, Marshall Island’s digital currency, Orion Protocol, and DUST Identity.
Pure Proof of Stake uses verifiable random function (VRF) as a weighted lottery where the weight is dependent on the number of ALGO’s someone owns.
VRF performs cryptographic sortition to select committees to run the consensus protocol. There are three parts to VRF, keygen, evaluate, and verify.
Y, our random string is unique and pseudorandom, it looks random, but with the proof, you can verify it with the verification algorithm.
In Algorand, each user (Algo holder online) runs through the steps above. They hold a secret key SK (secret key) and VK (verification key), the VK is known publicly, all handled out of band. If these users want to participate in the committee to run the consensus, then they need to do the following:
Compute Evaluate(SK, Qr) → (Y, ⍴). Here, Qr is a “magic” seed string available to everyone in the system.
Check that Y falls within a specific range [0, P] that depends on the user’s stake in the system.
Algorand shared their VRF algorithm with Libsodium, check out the implementation below:
Below is the standardization on VRF by Sharon Goldberg, Moni Naor, Dimitris Papadopoulos, Leonid Reyzin, and Jan Včelák:
A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the private key can compute the hash, but anyone with public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures.
An interesting feature of Algorand is that it’s not forkable.
Side Note on Forking
Forking happens if two nodes get a valid block simulataneously and different users can’t agree on which block to take or an upgrade can’t be decided on. In these scenarios the chain splits in two and as new blocks are added to the chain one of them will get longer than the other. Eventually the longest one will stay and the shortest one will die off. When the shortest chain dies off, all the blocks in it, along with all the transactions will be considered invalid.
Forking is not a bad thing.
Algorand is built to prevent forks. It isn’t necessarily a positive feature, just another way of tackling the CAP theorem (Consistency, Availability, and Partition Tolerant). With blockchain networks like Solana, forks are created to rotate leaders quickly. Forking allows the network to process transactions quickly and keep moving when there are disagreements but sacrifices consistency in the process.
The benefit around this is there’s an assurance that transactions reach finality once they are complete (~5 seconds). In forkable networks, you need to wait after a certain amount of blocks (6 blocks is recommended in Bitcoin, which could be an hour) are added on top of the block to know your transaction is in and it’s finalized.
How is Algorand Unforkable
Algorand is unforkable because two blocks can never be propagated to the chain at once because only one block can have the required threshold of committee votes.
Below are the steps in the Algorand Consensus Protocol:
Proposal Phase
Every node loops through online accounts with valid participation keys and selects an account. Now an account is selected, the other nodes verify the account was selected.
2. Soft Vote Phase
The number of proposals are narrowed down, and the nodes verify the signed messages and validate the selection using a VRF proof. The account with the lowest VRF hash is chosen to propose the next block.
3. Certify Vote Phase
A committee of 1,000 verifiers is pseudorandomly selected to receive information about the new block. Their job is to verify the block and mark it as valid or invalid. If the quorum is reached, the block is added to the blockchain.
If Quorum Not Reached — Network enters recovery mode but doesn’t fork
The network would never fork instead it will enter the recover mode. In recovery mode recovery messages are sent out. Nodes will send these messages to signal to the network that it should either continue processing the last known block proposal or to propose a new block.
When a quorum of votes is received for either one of these messages, the system will revert to normal operation.
In the case of malicious behavior, the protocol may select a new leader. In the case of network outage, the current block will continue to be processed or a new block might be proposed.
Check out the video below to learn more about Pure Proof of Stake.
Or check out the white paper on the protocol:
https://www.algorand.com/Algorand%20Protocol.pdf
The ledger uses SQLite database as its internal store. This is where the algod process writes and reads data.
SQLite was chosen as it provides excellent storage performance, is embedded, lightweight, and fault-tolerant. Other databases might provide better indexing features — but these are not required for an algorand node.
A drawback behind using SQLite is the lack of control from a database standpoint. For instance, your flexibility would be limited if you wanted to optimize the database like add indexes, etc. It’s not a deal-breaker but something to ponder if you’re considering Algorand for government or financial projects where the organization has its database management strategies.
Relational databases are rare in the blockchain space. The norm is key-value databases (i.e., Bitcoin & Ethereum uses LevelDB, Solana & Polkadot uses RocksDB). These databases are lightweight and easy to scale out horizontally. The only other platform that uses relational databases is Corda R3.
Indexer is a separate binary outside the Algorand node that acts as a REST API interface. It retrieves the blockchain data from a PostgresSQL database and is connected using an Algod process running on an Archival Algorand node.
Below is an example of a query where we return the last 1000 transactions that exceeded ten microAlgos:
#/indexer/python/search_transactions_min_amount.pyresponse = myindexer.search_transactions(min_amount=10)# Pretty Printing JSON string
print(json.dumps(response, indent=2, sort_keys=True))Accounts do not exchange messages directly; instead, they propagate their messages to a relay node. The relay node is untrustworthy, so to work around that, we use an encoding. One thing to keep in mind is that the relay nodes are permissioned nodes. They are registered with the Algorand foundation’s SRV records. This nudges Algorand towards a more centralized approach.
All messages in Algorand are encoded using MessagePack, a binary serialization format that allows exchanges in languages like JSON.
https://msgpack.org/?source=post_page-----e962f48f8c72--------------------------------
The network operates in a mesh network using WebSockets over HTTP (TCP). Algorand probably chose TCP because it’s commonly supported and can handle tasks like prioritizing queued messages.
The transaction pool, also called the mempool in other networks, is where the transactions are held in memory and added into a block proposal.
A transaction pool prepares valid blocks for proposals and caches validated transaction groups.
At all times, the transaction pool maintains a queue of transaction groups slated for proposal. It checks that the transactions are properly-signed, the fees meet the minimum, and the state changes are consistent with the prior transactions in the queue. It does all of this work within a deadline; if it doesn’t finish by the deadline, it gets a buffer period it puts together an empty or partial block.
With every transaction, there’s a minimum transaction fee of 1,000 microAlgos or .001 Algos. On top of that, there is a fee per byte based on the estimated size of the transaction in bytes. If this fee is less than the minimum fee, it defaults to the minimum fee. To better understand the fees, you can use the SDK method suggested fee per byte (fee).
Check out the fee documentation below for details:
In Algorand, there is a required minimum balance of 100,000 microAlgos (today that’s ~$0.092373). If your transaction gets the balance below this minimum, it will fail.
FeeSink is where all fees from transactions are sent. The FeeSink can only be spent towards the RewardsPool account. The RewardsPool account holds the Algos that need to be distributed as rewards to Algorand accounts in the protocol. As you can see in the code below, there’s a logic that only allows the FeeSink to send to the RewardPool.
This approach is slightly centralized, the reward pool is just one address on the Algorand network. Below is the reward pool for mainnet:
There are two processes in Algorand, there’s KMD and Algod.
KMD (Key Manager Daemon) handles all interactions with spending keys, including signing transactions. Signing can also be standalone.
Algod is responsible for processing the protocol and interacting with SQLite to write records and implement REST API for reads.
Algorand uses TEAL (Transaction Execution Approval Language) and REACH.
Algorand smart contracts like Ethereum smart contracts have an Algorand address and can hold Algorand Assets (ASA’s) and Algos.
Refer to the docs to learn more about smart contracts:
Algorand Developer Docs, SDKs, REST APIs, CLI tools, ecosystem projects, metrics dashboard and sample code, how-tos, and news from the Algorand developer community
TEAL is an assembly-like language that’s processed in AVM (Algorand Virtual Machines). It’s a Turing-complete language that supports looping and subroutines has guardrails that limit the contract’s execution time using a dynamic opcode cost evaluation algorithm. You can either write TEAL or use pyTEAL to generate TEAL code.
In pyTEAL and TEAL programs, there are always two programs: the Approval Program and the other is the Clear Program. The approval program contains most of the business logic, and the clear program handles closing the account(s).
All communication with Algorand smart contracts is achieved through application transactions. Below are the six application transaction subtypes.
Approval Program
As you can see in the NFT smart contract example below, all the meat sits in the approval program.
Clear State
from pyteal import *
def clear_state_program():
return Return(Int(1))
if __name__ == "__main__":
print(compileTeal(clear_state_program(), Mode.Application, version = 4))I pulled the smart contract above from Algo-Builder’s smart contract template:
Framework to automate development of Algorand Assets and Smart Contracts. - algo-builder/examples at master · scale-it/algo-builder
Reach is a DApp framework that works with Algorand and Ethereum, most commonly used with Algorand. Reach aims at handling the whole experience, frontend, and backend. The backend is dealt with a file like index.rsh and the frontend in an index.mjs.
Get your hands dirty with Reach by running through the tutorial below:
Standing up an Algorand is quite simple. You can even get away running on your laptop. Making it easier for several people to start running their Algorand nodes. Surprisingly, there aren’t many nodes running today, as of today, 1/31/21, there are only 1,427 nodes running. Giving that number some context, today, 1/31/21, there are 2,052 nodes running with Ethereum.
The relay nodes have to be registered with Algorand. In a truly decentralized blockchain, everyone and their mom should be able to run any node. Even though all these Relay Node participants are from different companies and countries, there is a point of centralization because they are all approved by the same organization.
Algorand has no minimum to participate in proof of stake, which allows anyone to participate in proof of stake. Every Algo token in Pure Proof of Stake (PPoS) (the consensus algorithm) is considered a lottery ticket. There’s a chance that the consensus would choose you with just one Algo, but the chances of being chosen increase with more “lottery” or Algos you have.
With Algorand’s no-fork design and its use of SQLite, I don’t see how it can scale. This approach of approving one block at a time, transactions could pile up if there isn’t a consensus on what’s proposed, stalling the network.
Because Algorand is unforkable, it’s highly secure, and transaction finality is everything regarding government and financial records.
The way they separate the processors, algod and kmd, makes the reads and writes secure. Key management should always be handled separately from other blockchain duties.
Algorand’s approach of not using spending keys to participate in consensus keeps the network secure. Instead, participants use a participation key and a collection of ephemeral keys to sign off on consensus activities like block proposals, votes, etc. This approach prevents double signing and protects spending keys from ever being jeopardized in the case of a compromised node.
Algorand is currently at around ~1,000 TPS, faster than Bitcoin and Ethereum, but not as fast as other 3rd generation blockchain networks like Solana. Algorand has proposed in their performance report that with block pipelining, they can reach 46,000 TPS, but we’ll need to wait for that implementation to deploy onto mainnet.
In terms of finality, Algorand wins; they have a finality of 2.5 seconds because it’s finalized as soon as the transaction completes. We don’t have to wait for additional blocks to be added to know it’s truly final because of its no forking design.
The Algorand Foundation pulled these performance metrics from their 2021 performance report:
Official Repo
Algorand's official implementation in Go. . Contribute to algorand/go-algorand development by creating an account on GitHub.
Algorand Metrics Dashboard
The AlgoGlobal Community works towards the goal of building a secure, scalable, decentralized network to serve as trusted public infrastructure for the common good.
Official Algorand Forum
The AlgoGlobal Community works towards the goal of building a secure, scalable, decentralized network to serve as trusted public infrastructure for the common good.
CoMakery Algorand Security Token
Open Source security token compatible with CoMakery, authored in collaboration with the Algorand Foundation team - CoMakery/algorand-security-token
Algorand Smart Contract Architecture
Tutorial on Atomic Transfers on Android
This is an android app developed on the Algorand Blockchain - gconnect/AlgorandPayrollContract
A few standup apps that use Algorand are Republic, Securitize, El Salvador’s blockchain infrastructure, Marshall Island’s digital currency, Orion Protocol, and DUST Identity.
Pure Proof of Stake uses verifiable random function (VRF) as a weighted lottery where the weight is dependent on the number of ALGO’s someone owns.
VRF performs cryptographic sortition to select committees to run the consensus protocol. There are three parts to VRF, keygen, evaluate, and verify.
Y, our random string is unique and pseudorandom, it looks random, but with the proof, you can verify it with the verification algorithm.
In Algorand, each user (Algo holder online) runs through the steps above. They hold a secret key SK (secret key) and VK (verification key), the VK is known publicly, all handled out of band. If these users want to participate in the committee to run the consensus, then they need to do the following:
Compute Evaluate(SK, Qr) → (Y, ⍴). Here, Qr is a “magic” seed string available to everyone in the system.
Check that Y falls within a specific range [0, P] that depends on the user’s stake in the system.
Algorand shared their VRF algorithm with Libsodium, check out the implementation below:
Below is the standardization on VRF by Sharon Goldberg, Moni Naor, Dimitris Papadopoulos, Leonid Reyzin, and Jan Včelák:
A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the private key can compute the hash, but anyone with public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures.
An interesting feature of Algorand is that it’s not forkable.
Side Note on Forking
Forking happens if two nodes get a valid block simulataneously and different users can’t agree on which block to take or an upgrade can’t be decided on. In these scenarios the chain splits in two and as new blocks are added to the chain one of them will get longer than the other. Eventually the longest one will stay and the shortest one will die off. When the shortest chain dies off, all the blocks in it, along with all the transactions will be considered invalid.
Forking is not a bad thing.
Algorand is built to prevent forks. It isn’t necessarily a positive feature, just another way of tackling the CAP theorem (Consistency, Availability, and Partition Tolerant). With blockchain networks like Solana, forks are created to rotate leaders quickly. Forking allows the network to process transactions quickly and keep moving when there are disagreements but sacrifices consistency in the process.
The benefit around this is there’s an assurance that transactions reach finality once they are complete (~5 seconds). In forkable networks, you need to wait after a certain amount of blocks (6 blocks is recommended in Bitcoin, which could be an hour) are added on top of the block to know your transaction is in and it’s finalized.
How is Algorand Unforkable
Algorand is unforkable because two blocks can never be propagated to the chain at once because only one block can have the required threshold of committee votes.
Below are the steps in the Algorand Consensus Protocol:
Proposal Phase
Every node loops through online accounts with valid participation keys and selects an account. Now an account is selected, the other nodes verify the account was selected.
2. Soft Vote Phase
The number of proposals are narrowed down, and the nodes verify the signed messages and validate the selection using a VRF proof. The account with the lowest VRF hash is chosen to propose the next block.
3. Certify Vote Phase
A committee of 1,000 verifiers is pseudorandomly selected to receive information about the new block. Their job is to verify the block and mark it as valid or invalid. If the quorum is reached, the block is added to the blockchain.
If Quorum Not Reached — Network enters recovery mode but doesn’t fork
The network would never fork instead it will enter the recover mode. In recovery mode recovery messages are sent out. Nodes will send these messages to signal to the network that it should either continue processing the last known block proposal or to propose a new block.
When a quorum of votes is received for either one of these messages, the system will revert to normal operation.
In the case of malicious behavior, the protocol may select a new leader. In the case of network outage, the current block will continue to be processed or a new block might be proposed.
Check out the video below to learn more about Pure Proof of Stake.
Or check out the white paper on the protocol:
https://www.algorand.com/Algorand%20Protocol.pdf
The ledger uses SQLite database as its internal store. This is where the algod process writes and reads data.
SQLite was chosen as it provides excellent storage performance, is embedded, lightweight, and fault-tolerant. Other databases might provide better indexing features — but these are not required for an algorand node.
A drawback behind using SQLite is the lack of control from a database standpoint. For instance, your flexibility would be limited if you wanted to optimize the database like add indexes, etc. It’s not a deal-breaker but something to ponder if you’re considering Algorand for government or financial projects where the organization has its database management strategies.
Relational databases are rare in the blockchain space. The norm is key-value databases (i.e., Bitcoin & Ethereum uses LevelDB, Solana & Polkadot uses RocksDB). These databases are lightweight and easy to scale out horizontally. The only other platform that uses relational databases is Corda R3.
Indexer is a separate binary outside the Algorand node that acts as a REST API interface. It retrieves the blockchain data from a PostgresSQL database and is connected using an Algod process running on an Archival Algorand node.
Below is an example of a query where we return the last 1000 transactions that exceeded ten microAlgos:
#/indexer/python/search_transactions_min_amount.pyresponse = myindexer.search_transactions(min_amount=10)# Pretty Printing JSON string
print(json.dumps(response, indent=2, sort_keys=True))Accounts do not exchange messages directly; instead, they propagate their messages to a relay node. The relay node is untrustworthy, so to work around that, we use an encoding. One thing to keep in mind is that the relay nodes are permissioned nodes. They are registered with the Algorand foundation’s SRV records. This nudges Algorand towards a more centralized approach.
All messages in Algorand are encoded using MessagePack, a binary serialization format that allows exchanges in languages like JSON.
https://msgpack.org/?source=post_page-----e962f48f8c72--------------------------------
The network operates in a mesh network using WebSockets over HTTP (TCP). Algorand probably chose TCP because it’s commonly supported and can handle tasks like prioritizing queued messages.
The transaction pool, also called the mempool in other networks, is where the transactions are held in memory and added into a block proposal.
A transaction pool prepares valid blocks for proposals and caches validated transaction groups.
At all times, the transaction pool maintains a queue of transaction groups slated for proposal. It checks that the transactions are properly-signed, the fees meet the minimum, and the state changes are consistent with the prior transactions in the queue. It does all of this work within a deadline; if it doesn’t finish by the deadline, it gets a buffer period it puts together an empty or partial block.
With every transaction, there’s a minimum transaction fee of 1,000 microAlgos or .001 Algos. On top of that, there is a fee per byte based on the estimated size of the transaction in bytes. If this fee is less than the minimum fee, it defaults to the minimum fee. To better understand the fees, you can use the SDK method suggested fee per byte (fee).
Check out the fee documentation below for details:
In Algorand, there is a required minimum balance of 100,000 microAlgos (today that’s ~$0.092373). If your transaction gets the balance below this minimum, it will fail.
FeeSink is where all fees from transactions are sent. The FeeSink can only be spent towards the RewardsPool account. The RewardsPool account holds the Algos that need to be distributed as rewards to Algorand accounts in the protocol. As you can see in the code below, there’s a logic that only allows the FeeSink to send to the RewardPool.
This approach is slightly centralized, the reward pool is just one address on the Algorand network. Below is the reward pool for mainnet:
There are two processes in Algorand, there’s KMD and Algod.
KMD (Key Manager Daemon) handles all interactions with spending keys, including signing transactions. Signing can also be standalone.
Algod is responsible for processing the protocol and interacting with SQLite to write records and implement REST API for reads.
Algorand uses TEAL (Transaction Execution Approval Language) and REACH.
Algorand smart contracts like Ethereum smart contracts have an Algorand address and can hold Algorand Assets (ASA’s) and Algos.
Refer to the docs to learn more about smart contracts:
Algorand Developer Docs, SDKs, REST APIs, CLI tools, ecosystem projects, metrics dashboard and sample code, how-tos, and news from the Algorand developer community
TEAL is an assembly-like language that’s processed in AVM (Algorand Virtual Machines). It’s a Turing-complete language that supports looping and subroutines has guardrails that limit the contract’s execution time using a dynamic opcode cost evaluation algorithm. You can either write TEAL or use pyTEAL to generate TEAL code.
In pyTEAL and TEAL programs, there are always two programs: the Approval Program and the other is the Clear Program. The approval program contains most of the business logic, and the clear program handles closing the account(s).
All communication with Algorand smart contracts is achieved through application transactions. Below are the six application transaction subtypes.
Approval Program
As you can see in the NFT smart contract example below, all the meat sits in the approval program.
Clear State
from pyteal import *
def clear_state_program():
return Return(Int(1))
if __name__ == "__main__":
print(compileTeal(clear_state_program(), Mode.Application, version = 4))I pulled the smart contract above from Algo-Builder’s smart contract template:
Framework to automate development of Algorand Assets and Smart Contracts. - algo-builder/examples at master · scale-it/algo-builder
Reach is a DApp framework that works with Algorand and Ethereum, most commonly used with Algorand. Reach aims at handling the whole experience, frontend, and backend. The backend is dealt with a file like index.rsh and the frontend in an index.mjs.
Get your hands dirty with Reach by running through the tutorial below:
Standing up an Algorand is quite simple. You can even get away running on your laptop. Making it easier for several people to start running their Algorand nodes. Surprisingly, there aren’t many nodes running today, as of today, 1/31/21, there are only 1,427 nodes running. Giving that number some context, today, 1/31/21, there are 2,052 nodes running with Ethereum.
The relay nodes have to be registered with Algorand. In a truly decentralized blockchain, everyone and their mom should be able to run any node. Even though all these Relay Node participants are from different companies and countries, there is a point of centralization because they are all approved by the same organization.
Algorand has no minimum to participate in proof of stake, which allows anyone to participate in proof of stake. Every Algo token in Pure Proof of Stake (PPoS) (the consensus algorithm) is considered a lottery ticket. There’s a chance that the consensus would choose you with just one Algo, but the chances of being chosen increase with more “lottery” or Algos you have.
With Algorand’s no-fork design and its use of SQLite, I don’t see how it can scale. This approach of approving one block at a time, transactions could pile up if there isn’t a consensus on what’s proposed, stalling the network.
Because Algorand is unforkable, it’s highly secure, and transaction finality is everything regarding government and financial records.
The way they separate the processors, algod and kmd, makes the reads and writes secure. Key management should always be handled separately from other blockchain duties.
Algorand’s approach of not using spending keys to participate in consensus keeps the network secure. Instead, participants use a participation key and a collection of ephemeral keys to sign off on consensus activities like block proposals, votes, etc. This approach prevents double signing and protects spending keys from ever being jeopardized in the case of a compromised node.
Algorand is currently at around ~1,000 TPS, faster than Bitcoin and Ethereum, but not as fast as other 3rd generation blockchain networks like Solana. Algorand has proposed in their performance report that with block pipelining, they can reach 46,000 TPS, but we’ll need to wait for that implementation to deploy onto mainnet.
In terms of finality, Algorand wins; they have a finality of 2.5 seconds because it’s finalized as soon as the transaction completes. We don’t have to wait for additional blocks to be added to know it’s truly final because of its no forking design.
The Algorand Foundation pulled these performance metrics from their 2021 performance report:
Official Repo
Algorand's official implementation in Go. . Contribute to algorand/go-algorand development by creating an account on GitHub.
Algorand Metrics Dashboard
The AlgoGlobal Community works towards the goal of building a secure, scalable, decentralized network to serve as trusted public infrastructure for the common good.
Official Algorand Forum
The AlgoGlobal Community works towards the goal of building a secure, scalable, decentralized network to serve as trusted public infrastructure for the common good.
CoMakery Algorand Security Token
Open Source security token compatible with CoMakery, authored in collaboration with the Algorand Foundation team - CoMakery/algorand-security-token
Algorand Smart Contract Architecture
Tutorial on Atomic Transfers on Android
This is an android app developed on the Algorand Blockchain - gconnect/AlgorandPayrollContract
from pyteal import *
def approval_program():
"""
This smart contract implements a Non Fungible Token
Each NFT is an (ID, ref_data, hash) triple.
NFT ID is the total count of NFT's in asc.
ref-data is represented as "https://nft-name/<total>/nft-ref"
hash is an hash of the external resources data.
Commands:
create Creates a new NFT. Expects 2 additional arguments:
* nft-ref: a reference data (usually a URL or CID)
* nft-ref-hash: a hash of the underlying reference data
Only creator can create new NFTs.
transfer Transfers an NFT between two accounts. Expects one additional arg: NFT_ID.
Additionally, two Accounts(from, to) must also be passed to the smart contract.
"""
var_total = Bytes("total")
var_1 = Int(1)
# Check to see that the application ID is not set, indicating this is a creation call.
# Store the creator address to global state.
# Set total nft count to 0
on_deployment = Seq([
App.globalPut(Bytes("creator"), Txn.sender()),
Assert(Txn.application_args.length() == Int(0)),
App.globalPut(var_total, Int(0)),
Return(var_1)
])
# Always verify that the RekeyTo property of any transaction is set to the ZeroAddress
# unless the contract is specifically involved ina rekeying operation.
no_rekey_addr = Txn.rekey_to() == Global.zero_address()
# Checks whether the sender is creator.
is_creator = Txn.sender() == App.globalGet(Bytes("creator"))
# Get total amount of NFT's from global storage
create_nft_id = Itob(App.globalGet(var_total))
# create transaction parameters
data_ref = Txn.application_args[1]
data_hash = Txn.application_args[2]
# var to store id_h
id_h = ScratchVar(TealType.bytes)
# Verifies if the creater is making this request
# Verifies three arguments are passed to this transaction ("create", nft-name, nft-ref)
# Increment Global NFT count by 1
# Assign data_ref to NFT ID (= total)
# Assign hash of nft-ref to ID_h
# Add above two keys to global and creator's local storage
create_nft = Seq([
Assert(And(
Txn.application_args.length() == Int(3),
is_creator,
no_rekey_addr
)),
App.globalPut(var_total, App.globalGet(var_total) + var_1),
id_h.store(Concat(create_nft_id, Bytes("_h"))), # store id_h in scratchVar
App.globalPut(create_nft_id, data_ref),
App.globalPut(id_h.load() , data_hash),
App.localPut(Int(0), create_nft_id, var_1), # Int(0) represents the address of caller
Return(is_creator)
])
transfer_nft_id = Txn.application_args[1] # this is only in the transfer condition
# Verify two arguments are passed
# Verify NFT_ID is present in global storage
# Add nft to account_2's local storage
# Remove nft from account_1's local storage
transfer_nft = Seq([
Assert(And(
Txn.application_args.length() == Int(2),
no_rekey_addr,
# assert that a account_1 holds the NFT
App.localGet(var_1, transfer_nft_id) == var_1
)),
App.localDel(var_1, transfer_nft_id),
App.localPut(Int(2), transfer_nft_id, var_1),
Return(var_1)
])
# Verfies that the application_id is 0, jumps to on_deployment.
# Verifies that DeleteApplication is used and verifies that sender is creator.
# Verifies that UpdateApplication is used and blocks that call (unsafe for production use).
# Verifies that closeOut is used and jumps to on_closeout.
# Verifies that the account has opted in and jumps to on_register.
# Verifies that first argument is "vote" and jumps to on_vote.
program = Cond(
[Txn.application_id() == Int(0), on_deployment],
[Txn.on_completion() == OnComplete.UpdateApplication, Return(Int(0))], #block update
[Txn.on_completion() == OnComplete.DeleteApplication, Return(is_creator)],
[Txn.on_completion() == OnComplete.CloseOut, Return(var_1)],
[Txn.on_completion() == OnComplete.OptIn, Return(var_1)],
[Txn.application_args[0] == Bytes("create"), create_nft],
[Txn.application_args[0] == Bytes("transfer"), transfer_nft]
)
return program
if __name__ == "__main__":
print(compileTeal(approval_program(), Mode.Application, version = 4))from pyteal import *
def approval_program():
"""
This smart contract implements a Non Fungible Token
Each NFT is an (ID, ref_data, hash) triple.
NFT ID is the total count of NFT's in asc.
ref-data is represented as "https://nft-name/<total>/nft-ref"
hash is an hash of the external resources data.
Commands:
create Creates a new NFT. Expects 2 additional arguments:
* nft-ref: a reference data (usually a URL or CID)
* nft-ref-hash: a hash of the underlying reference data
Only creator can create new NFTs.
transfer Transfers an NFT between two accounts. Expects one additional arg: NFT_ID.
Additionally, two Accounts(from, to) must also be passed to the smart contract.
"""
var_total = Bytes("total")
var_1 = Int(1)
# Check to see that the application ID is not set, indicating this is a creation call.
# Store the creator address to global state.
# Set total nft count to 0
on_deployment = Seq([
App.globalPut(Bytes("creator"), Txn.sender()),
Assert(Txn.application_args.length() == Int(0)),
App.globalPut(var_total, Int(0)),
Return(var_1)
])
# Always verify that the RekeyTo property of any transaction is set to the ZeroAddress
# unless the contract is specifically involved ina rekeying operation.
no_rekey_addr = Txn.rekey_to() == Global.zero_address()
# Checks whether the sender is creator.
is_creator = Txn.sender() == App.globalGet(Bytes("creator"))
# Get total amount of NFT's from global storage
create_nft_id = Itob(App.globalGet(var_total))
# create transaction parameters
data_ref = Txn.application_args[1]
data_hash = Txn.application_args[2]
# var to store id_h
id_h = ScratchVar(TealType.bytes)
# Verifies if the creater is making this request
# Verifies three arguments are passed to this transaction ("create", nft-name, nft-ref)
# Increment Global NFT count by 1
# Assign data_ref to NFT ID (= total)
# Assign hash of nft-ref to ID_h
# Add above two keys to global and creator's local storage
create_nft = Seq([
Assert(And(
Txn.application_args.length() == Int(3),
is_creator,
no_rekey_addr
)),
App.globalPut(var_total, App.globalGet(var_total) + var_1),
id_h.store(Concat(create_nft_id, Bytes("_h"))), # store id_h in scratchVar
App.globalPut(create_nft_id, data_ref),
App.globalPut(id_h.load() , data_hash),
App.localPut(Int(0), create_nft_id, var_1), # Int(0) represents the address of caller
Return(is_creator)
])
transfer_nft_id = Txn.application_args[1] # this is only in the transfer condition
# Verify two arguments are passed
# Verify NFT_ID is present in global storage
# Add nft to account_2's local storage
# Remove nft from account_1's local storage
transfer_nft = Seq([
Assert(And(
Txn.application_args.length() == Int(2),
no_rekey_addr,
# assert that a account_1 holds the NFT
App.localGet(var_1, transfer_nft_id) == var_1
)),
App.localDel(var_1, transfer_nft_id),
App.localPut(Int(2), transfer_nft_id, var_1),
Return(var_1)
])
# Verfies that the application_id is 0, jumps to on_deployment.
# Verifies that DeleteApplication is used and verifies that sender is creator.
# Verifies that UpdateApplication is used and blocks that call (unsafe for production use).
# Verifies that closeOut is used and jumps to on_closeout.
# Verifies that the account has opted in and jumps to on_register.
# Verifies that first argument is "vote" and jumps to on_vote.
program = Cond(
[Txn.application_id() == Int(0), on_deployment],
[Txn.on_completion() == OnComplete.UpdateApplication, Return(Int(0))], #block update
[Txn.on_completion() == OnComplete.DeleteApplication, Return(is_creator)],
[Txn.on_completion() == OnComplete.CloseOut, Return(var_1)],
[Txn.on_completion() == OnComplete.OptIn, Return(var_1)],
[Txn.application_args[0] == Bytes("create"), create_nft],
[Txn.application_args[0] == Bytes("transfer"), transfer_nft]
)
return program
if __name__ == "__main__":
print(compileTeal(approval_program(), Mode.Application, version = 4))Mabel Oza
Mabel Oza
No activity yet