algorand-school-english.txt

Algorand School

2023







Open Source: github.com/cusma/algorand-school

Our journey today:

understanding Algorand Consensus and Algorand Networks, how to use Algorand Dev Tools, how to develop decentralized applications on the Algorand Virtual Machine

Agenda

Blockchain as an infrastructure
Analog properties for Digital things
Algorand Consensus
Algorand Sustainability
Algorand Networks
Algorand Interoperability
Algorand Transactions
Algorand Accounts
Algorand Standard Assets & ARCs
Algorand Virtual Machine
Algorand Smart Contracts on Layer-1
Smart Signatures & Smart Contracts
TEAL
PyTEAL
Algorand ABI
Beaker

4
Introduction to Algorand
An efficient public infrastructure for digital value






Cosimo Bassi
Solutions Architect at Algorand

cosimo.bassi@algorand.com


Blockchain is a digital infrastructure for value
6
"The ability to create something which is not duplicable in the digital world has enormous value."

Eric Schmidt


The infrastructure trilemma
7
TRILEMMA
2
3
1
SECURITY (INT/EXT)
ACCESSIBILITY
EFFICIENCY
Public or private? Who has the control? Duty and responsibility? Aligned incentives?


The problem of native digital value
8
In the digital age
everything can be represented in bits 
as a string of 0 and 1
Strings of 0 and 1 are useful
because you can
duplicate them easily
Value is therefore difficult to represent in the digital age:
SCARCITY, AUTHENTICITY, UNICITY


How to build such infrastructure? Protocol is the answer
9
Just like TCP/IP is the foundational protocol for the modern Internet infrastructure, we will solve the problem through an protocol.

This is not just an information technology problem
10
DISTRIBUTED SYSTEMS
CRYPTOGRAPHY
GAME THEORY
PUBLIC
TAMPER-PROOF
TRANSPARENT
TRUSTLESS
LEDGER
Distributed systems and cryptography are elements of the communication infrastructure. We need a third element: game theory.

Who controls the system? Nobody… everybody!
11
PAST
FUTURE
DISTRIBUTED SYSTEMS
No absolute power, no single point of failure.


Don’t trust, verify!
12
Nobody can break the rules…
and
…everybody can verify.
CRYPTOGRAPHY


Align incentives: collective self-protecting system
13
GAME THEORY
Equilibrium in which attacking the system is less convenient than protecting it.

Cost of the attack: make malicious behaviours expensive.


14
ANALOG PROPERTIES
FOR DIGITAL THINGS
Consensus as “law of Physics” for digital world

Who owns what? Let’s write it down!
15
A blockchain is a public ledger of transactional data.
World's first writing — cuneiform — traces its beginnings back to an ancient system of accounting.
WHO

OWNS

WHAT
Writing systems: from prehistory to history of humankind.

More copies are better than one!
16
Distributed and replicated across a system of multiple nodes in a network.
All “ledger keepers” should work together, using the same set rules, to verify the transactions to add to each copy of the finalized ledger. 


17
Atoms can’t be copy & pasted and are obliged to follow the arrow of time!
Bits can be copy & pasted and are not obliged to follow the arrow of time!
Entropy, irreversibility and the arrow of time
In a distributed system is hard to ensure that the information follows a consequential time. Also, the arrow of time could bypassed reverting transactions. The ledger of information must respect a precise history and must not allow arbitrary creation, duplication or deletion of information. 

A chain of transactions organized in blocks
18
The “block” refers to a set of transactions that are proposed and verified by the other nodes and eventually added to the ledger (no copy & paste).
The “chain” refers to the fact that each block of transactions contains proof (a cryptographic hash) of what was in the previous block (arrow of time).





Can transactions be reverted or modified ex-post? No! Dura lex, sed lex!


A distributed state machine
19
A machine
The evolution of the states of the system is determined…

SYSTEM STATE
S0

SYSTEM STATE
Sn

SYSTEM STATE
S1
BLOCK N
SMART CONTRACT
TRANSACTION
The evolution of the states of the system is determined…
…acting on atoms, through the inviolable laws of Physics!
…acting on bits, through what?
BLOCK 1
SMART CONTRACT
TRANSACTION
The more complex the state transition the more power I consume: adding 1 transaction per month is easy, executing thousands of smart contracts on the AVM is complicated.

The responsibility of correct information
20
Margaret Hamilton in 1969, standing next to listings of the software she and her MIT team produced for the Apollo project.
BLOCK PROPOSER
GENESIS BLOCK
BLOCK 1
BLOCK N
BLOCK N+1
How should we replace the role played by the law of Physics in evolving the state of a machine?

With a set of software rules, called Consensus Protocol that evolves the state of the system. 
Paleo-computing: no IDE, no syntax highlighting, handwritten code (value of conciseness).

The architecture of consensus
21
Temple of Concordia
Valley of Temples (Agrigento), 440-430 B.C.
How to choose the proposer for the next block for a public and permissionless blockchain?

How to ensure that there is no ambiguity in the choice of the next block?

How to ensure that the blockchain stays unique and has no forks?

How to ensure that consensus mechanism itself can evolve over time while the blockchain is an immutable ledger?
It is the largest and best-preserved Doric temple in Sicily[5] and one of the best-preserved Greek temples in general,[1] especially of the Doric order. Named after Concordia.
In ancient Roman religion, Concordia is the goddess who embodies agreement in society. Her Greek equivalent is usually regarded as Harmonia, with musical harmony a metaphor for an ideal of social concord.
This tells us a lot about the value of such a civilization!

Proof of Work consensus mechanism
22
Miners compete with each other to append the next block and earn a reward for the effort, fighting to win an expensive computational battle.
The more computational power, the higher the probability of being elected as block proposer.
PoW


Proof of Work limits
23
Huge electrical consumption

Concentration of governance in few mining farms

Soft-forking of the blockchain


Proof of Stake consensus mechanism
24
Network participants show their commitment and interest in keeping the ledger safe and secure proving the ownership of value stored on the ledger itself.

The higher the skin in the game the higher the probability of being elected as block proposer.


Proof of Stake limits
25
CRITICAL ISSUES
BONDED PROOF OF STAKE
Validators bind their stake, to show their commitment in validating and appending a new block. Misbehaviors are punished.
Participating in the consensus protocol makes users’ stakes illiquid
Risk of economic barrier to entry
DELEGATED PROOF OF STAKE
Users delegate the validation of new blocks to a fixed committee, through weighted voting based on their stakes.
Known delegate nodes, therefore exposed to DDoS attacks
Centralization of governance
BPoS
DPoS
It’s like playing Battleship knowing the coordinates of adversary in advance.

Is the Blockchain Trilemma unsolvable?
26
TRILEMMA
2
3
1
SECURITY
SCALABILITY
DECENTRALIZATION


27
ALGORAND CONSENSUSPure Proof of Stake (PPoS)

Scalable		6000 TPS, billions of users
Fast			< 3.9 s per block
Secure		0 downtime for over 23M blocks
Low fees		0.001 ALGO per txn
No Soft Forks 	prob. < 10-18
Instant Transaction Finality
Carbon neutral
Minimal hardware node requirements
No delegation or binding of the stake
No minimum stake
Secure with respect DDoS
Network Partitioning resilience
Algorand PPoS Consensus
28
Silvio Micali  Algorand Founder
Professor MIT, Turing Award, Gödel Prize
Digital Signatures, Probabilistic Encryption, Zero-Knowledge Proofs,
Verifiable Random Functions and other primitives of modern cryptography.

Flat fee is very powerful for business models: given a users base, an estimation of users activity (tx/day) a business team can foresee the costs and hedge the on-chain resources.

Tamper-proof, unique and verifiable dices
29





VRF
Dices are perfectly balanced and equiprobable, nobody could tamper their result!
Keep observing dice rolls by no means increases the chance of guessing the next result!
Each dice is uniquely signed by its owner, nobody can roll someone else dices!
Dices are publicly verifiable, everybody can read the results of a roll!


Who chose the next block?
30
VRF
VRF
VRF
VRF
WIN!
Each ALGO could be assimilated to a tamper-proof dice participating in a safe and secret cryptographic dice roll. More ALGOs more dices to roll.

For each new block, dice rolls are performed in a distributed, parallel and secret and manner, directly on online accounts’ hardware (in microseconds).

The winner is revealed in a safe and verifiable way only after winning the dice roll, proposing the next block.


A glimpse on “simplified” VRF sortition
31
A secret key (SK) / public verification key (VK) pair is associated with each ALGO in the account
For each new round r of the consensus protocol a threshold L(r) is defined
Each ALGO in the account performs a VRF, using its own secret key (SK), to generate:
a pseudo-random number:		Y = VRFSK(seed)
the verifiable associated proof:	⍴SK(seed)
If Y = VRFSK(seed) < L(r), that specific ALGO “wins the lottery” and viraly propagates the proof of its victory ⍴SK(seed) to other network’s nodes, through “gossiping” mechanism
Others node can use the public verification key (VK) to verify, through ⍴SK(seed), that the number Y was generated by that specific ALGO, owned by the winner of the lottery


Pure Proof of Stake, in short
32
Through the cryptographic lottery, an online account is elected with probability directly proportional to its stake: each ALGO corresponds to an attempt to win the lottery!




An account is elected to propose the next block
A committee is elected to filter and vote on the block proposals
A new committee is elected to reach a quorum and certify the block
The new block is appended to the blockchain
Each round of the consensus protocol appends a new block in the blockchain:


Ok, but… how long does it take?
33


Less than 3.9 seconds!
34


Pure Proof of Stake security
35
Algorand’s decentralized Byzantine consensus protocol can tolerate an arbitrary number of malicious users as long as honest users hold a super majority of the total stake in the system.
The adversary does not know which users he should corrupt.
The adversary realizes which users are selected too late to benefit from attacking them. 
Each new set of users will be privately and individually elected.
During a network partition in Algorand, the adversary is never able to convince two honest users to accept two different blocks for the same round.
Algorand is able to recover shortly after network partition is resolved and guarantees that new blocks will be generated at the same speed as before the partition.


Pure Proof of Stake: the output pre-upgrade!
36
BLOCKS
> 32M with 0 downtime
BLOCKCHAIN SIZE
~ 1 TB
ADDRESSES
> 32M with ~ 1M monthly active addresses
AVG. BLOCK FINALIZATION
~ 3.5 sec per block
TXNS WEEKLY VOLUME
~ 5M transactions (September 2023)
TPS WEEKLY PEAK
~ 6000 transactions per second
* up to August 2022
This is the output that such a complex machine has produced so far… We still have to answer to the opening question: “is this machine good at consuming input resources to produce the desired output for which it has been designed for?”

Algorand Layer-1 primitives
37

Algorand Standard Assets (ASA)

Atomic Transfers
(AT)

Algorand Virtual Machine (AVM)





Algorand State Proof (ASP)




TRUSTLESS
INTEROPERABLE
POST-QUANTUM SECURE





What does execution on Layer-1 mean?
38
B1
B2
...
Br
ASC1 CALL
ASC1 CALL
ASC1 CALL
TXN 1
ASC1 CALL
L-1 CONSENSUS COMMITTEE

3.8 sec
L-1 CONSENSUS COMMITTEE

3.8 sec
L-1 CONSENSUS COMMITTEE

3.8 sec
EXECUTION ON PPoS CONSENSUS LEVEL
up to 25000 txn/block
up to 25000 txn/block
AVM execution does not slow down the whole blocks production!
up to 25000 txn/block
up to 25000 txn/block
Each complex system is characterised by a “natural pulsation”. For electrical networks is the grid’s frequency, for automated assembly lines is the production tack-time. We, humans, are complex systems, our natural pulsations is the heartbeat. Block time is Algorand’s heartbeat!

What does execution on Layer-1 mean?
39
Smart Contracts are executed “at consensus level”
Benefit from network's speed, security, and scalability
Fast trustless execution (~3.8 seconds per block)
Low cost execution (0.001 ALGO regardless SC’s complexity)
Instant Finality of Smart Contracts’ effects
Native interoperability with Layer-1 primitives
Safe high level languages (PyTeal, Reach, Clarity)
Low energy consumption


40
ALGORAND SUSTAINABILITY“Permission-less” is not “Responsibility-less”
Full paper: “Proof of Stake Blockchain Efficiency Framework”

“Permission-less” is not “Responsibility-less”
41
Algorand is a permission-less network 🕸, so no centralized authority can know or impose how node runners should power their nodes 💻.
As decentralized infrastructure, Algorand is responsible for its impact on Planet Earth 🌏, although no centralized authority controls it.
Algorand should acts proactively (not hiding behind the “permission-less excuse”) and set blockchains’ sustainability bar high 🌱.


Proof of unsustainable Work
42
Proof of Work is a planetary wasteful computational battle, in which miners MUST burn energy to secure the blockchain.
Showing off personal commitment in the ecosystem through the consumption of computational and energetic resources is at the core of PoW consensus mechanism.

Our planet Earth can no longer afford unsustainable technologies.


43
A matter of orders of magnitude (PoW vs PPoS)
Eiffel Tower
Paper sheet thickness
2x Burj Khalifa
103
102
10-5
Full paper: “Proof of Stake Blockchain Efficiency Framework”


44
You like to win easy!
What about others Proof of Stake?


When the going gets tough, the tough get going (PoS vs PPoS)
45
Blockchain sustainability must consider scalable end-user transactions (uTPS) finality (f), nodes hardware (N), and secure network decentralization (d).





Being sustainable while centralized, insecure or not scalable
is worthless!
DECENTRALIZED
SECURE
NETWORK
(running on Consensus Protocol)

(f, N, d)
INPUT
OUTPUT
POWER
(Pval)
END-USER
FINALIZED
TRANSACTIONS
(uTPS)


Reframing the question
46
Is Algorand blockchain efficient
at consuming energy 
to finalize end user useful transactions
in a secure, scalable and decentralized way?


Algorand solves blockchain trilemma sustainably
47
Algorand transactions are 100% available to end-users
(other PoS blockchains consume their own transactions for consensus)
Algorand transactions are 100% instantly final
(other PoS must consume the energy of several blocks to ensure transactions’ finality)
Algorand transactions are secured by a very decentralized network
(some PoS blockchain have only few validators)
Algorand security is a feature of its own efficiency
(Algorand never experienced downtime since the genesis block)
Full paper: “Proof of Stake Blockchain Efficiency Framework”


48
ALGORAND NETWORKSNodes, Indexer and APIs

Algorand Node configurations
49
Non-Relay Nodes
Participate in the PPoS consensus (if hosting participation keys)
Connect only to Relay Nodes 
Light Configuration: store just the lastest 1000 blocks (Fast Catch-Up)
Archival Configuration: store all the chain since the genesis block

Relay Nodes
Communication routing to a set of connected Non-Relay Nodes
Connect both with Non-Relay Nodes and Relay Nodes
Route blocks to all connected Non-Relay Nodes
Highly efficient communication paths, reducing communication hops


Example of Algorand Network topology
50
Node Metrics
Non-Relay Nodes: 	> 1100
Relay Nodes:		> 120


51
Access to Algorand Network
The Algorand blockchain is a distributed system of nodes each maintaining their local state based on validating the history of blocks and the transactions therein. Blockchain state integrity is maintained by the consensus protocol which is implemented within the Algod daemon (often referred to as the node software).

An application connects to the Algorand blockchain through an Algod client, requiring:

a valid Algod REST API endpoint IP address
an Algod token from an Algorand node connected to the network you plan to interact with

These two pieces of information can be provided by your local node or by a third party node aaS.


52
How to get an Algod Client?
There are three ways to get a REST API Algod endpoint IP address / access token, each with their respective pros and cons depending on development goals.


53
Algorand Networks


54
Algorand Node -  Writing on the blockchain
Install (Linux, MacOS, Windows)
Choose a network (MainNet, TestNet, BetaNet, PrivateNet)
Start & Sync with the network, Fast Catchup

genesis.json (mainnet)

{
  "alloc": [
    {
      "addr": "7377777777777777...77777777UFEJ2CI",
      "comment": "RewardsPool",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "Y76M3MSY6DKBRHBL7C3...F2QWNPL226CA",
      "comment": "FeeSink",
      "state": {
        "algo": 1000000,
        "onl": 2
      }
    },
    ...
  ],
  "fees": "Y76M3MSY6DKBRHBL7C3NNDX...F2QWNPL226CA",
  "id": "v1.0",
  "network": "mainnet",
  "proto": "https://github.com/algorandfoundation/specs/tree/5615adc36bad610c7f165fa2967f4ecfa75125f0",
  "rwd": "737777777777777777777...77777777UFEJ2CI",
  "timestamp": 1560211200
}
Interacting with Algorand Nodes
CLI utilities: 		goal, kmd and algokey
REST API interface: 	algod V2, kmd, indexer
Algorand SDKs: 		JavaScript, Python, Java o Go


55
Algorand Indexer - Reading from the blockchain
The Indexer provides a REST API interface of API calls to query the Algorand blockchain. The Indexer REST APIs retrieves blockchain data from a PostgreSQL database, populated using the Indexer instance connected to an Archival Algorand node that reads blocks’ data. As with the Nodes, the Indexer can be used as a third-party service.


Which node configuration do I need?
56
I want to participate in consensus and help secure the Algorand network.
➥ non-relay non-archival participation node.
I want to send transactions and read current state of smart contracts/applications:
➥ non-relay non-archival non-participation node.
I want full access to historical data (blocks, transactions) with advanced querying:
➥ non-relay archival non-participation node, together with an indexer.
I want to get state proofs for any block:
➥ non-relay archival non-participation node.
I want  just to have access to non self hosted Algod and Indexer end-points for your Web3 project:
➥ use a third-party Algorand API-aaS (e.g. AlgoNode).


57
How to interact with Algorand Node and Indexer


58
AlgoKit: Algorand’s dev one-stop-shop


59
Algorand Community SDKs
Java
JavaScript
Python
Go
C#
Rust
Dart
PHP
Algorand SDKs
Swift


60
Algorand Developer Portal


61
Awesome Algorand


62
Algorand Wallets
Pera Wallet + Wallet Connect
MetaMask
DeflyApp


63
Algorand Explorers
Dappflow


64
ALGORAND INTEROPERABILITYState Proofs and Post-Quantum Security
Credits to Noah Grossman for contents

Trustless interoperability
65
Algorand approach to interoperability:
cross-chain transactions should rely just on
Trust in departing consensus protocol
Trust in arrival consensus protocol
without centralized bridges or validator networks, to handle the assets.

Algorand State Proofs remove trusted centralized operators becoming the first trustless post-quantum secure L1 interoperability standard.


Post-Quantum Secure Algorand State Proofs
66
Post-Quantum secure and immutable proofs, attesting blockchain state, generated by Pure Proof of Stake consensus protocol.


67
ALGORAND TRANSACTIONS
Core element of blocks

Changing blockchain state
68
Transactions are the core element of blocks, which define the evolution of distributed ledger state. There are six transaction types in the Algorand Protocol:
Payment
Key Registration
Asset Configuration
Asset Freeze
Asset Transfer
Application Call

These six transaction types can be specified in particular ways that result in more granular perceived transaction types.


Signature, fees and round validity
69
In order to be approved, Algorand’s transactions must comply with:

Signatures: transactions must be correctly signed by its sender, either a Single Signature, a Multi Signature or a Smart Signature / Smart Contract
Fees: in Algorand transactions fees are a way to protect the network from DDoS. In Algorand Pure PoS fees are not meant to pay “validation” (as it happens in PoW blockchains). In Algorand you can delegate fees.
Round validity: to handle transactions’ idempotency, letting Non-Archival nodes participate in Algorand Consensus, transactions have an intrinsic validity of 1000 blocks (at most). 


Browse through a transaction
70
Transactions are characterized by two kind of fields (codec):

common (header)
specific (type)


Payment Transaction example
71
Here is a transaction that sends 5 ALGO from one account to another on MainNet.


72
ALGORAND ACCOUNTS
Transactions’ Authorization

Signatures
73
SECRET KEY
32 bytes
PUBLIC KEY
32 bytes
Ed25519
GENERATOR
Algorand uses Ed25519 high-speed, high-security elliptic-curve signatures.
ALGORAND ADDRESS
58 characters
MNEMONIC PHRASE
25 words
RANDOM SEED
ADDRESS: the public key is transformed into an Algorand Address, by adding a 4-byte checksum to the end of the public key and then encoding it in base32.

MNEMONIC: the 25-word mnemonic is generated by converting the private key bytes into 11-bit integers and then mapping those integers to the bip-0039 English word list.


Algorand Accounts
74
Accounts are entities on the Algorand blockchain associated with specific on-chain local sate. An Algorand Address is the unique identifier for an Algorand Account.
All the potential keys pairs “already exists” mathematically, we just keep discovering them.


Transactions Authorization and Rekey-To
75
PUBLIC ADDRESS
MULTI SIGNATURE ACCOUNT
LOCAL STATE
SECRET KEY [1/N]
PUBLIC ADDRESS
STANDARD ACCOUNT
LOCAL STATE
SECRET KEY
CONTRACT ACCOUNT
SECRET KEY [k/N]
SECRET KEY [N/N]
Algorand Rekeying: powerful Layer-1 protocol feature which enables an Algorand account to maintain a static public address while dynamically rotating the authoritative private spending key(s). Any Account can Rekey either to a Standard Account, MultiSig Account or LogicSig Contract Account.
PUBLIC ADDRESS
SMART SIG
LOCAL STATE


Account State Minimum Balance
76


77
ASAAlgorand Standard Assets on Layer-1

Algorand Standard Assets
78
Algorand Standard Asset (ASA) is the native L1 Algorand tokenization framework.
ASAs do not require writing Smart Contracts!
ASAs can be minted and configured with simple transactions (SDKs / CLI).
ASAs are suitable to tokenize different assets, like:
Fungible assets;
NFT;
Stablecoins;
Loyalty points;
Etc.


Base Params (Immutable)
79
Parameter
Description
Required
Creator
Any Algorand Account: SingleSig / MultiSig / SmartSig / App
YES
Asset Name
Extended Asset name
NO
Unit Name
Asset Unit short name
NO
MetaData Hash
Hash of asset’s metadata. 
NO
URL
Link to external data attached to the asset.
NO
Example 1: I want to link the PDF containing the asset’s prospectus and terms of usage to the ASA.
➥ Set the asset URL to PDF hosting URL and the asset metadata hash to the SHA-512/256 of the linked PDF (to guarantee attachment immutability).
Example 2: I want to link an image to an NFT.
➥ Set the asset URL to IPFS CID of the image (see ARC standards sections).


Quantitative Params (Immutable)
80
Parameter
Description
Required
Total
Integer supply of least significant units
YES
Decimals
Client-side interpretation of asset’s decimals positions.
YES
Example 1: I want to be able to increase the asset supply over time (e.g. a stablecoin).
➥ Set the asset total to the maximum allowed by the ledger (264 - 1) and place the total supply in the Reserve (not accounted as circulating supply), then transfer from Reserve to other accounts releasing the circulating supply over time.
Example 2: I want to mint a Non-Fractional NFT.
➥ Set the asset total to 1 and decimals to 0.
Example 3: I want to mint a Fractional NFT, divisible up to 0.01.
➥ Set the asset total to 100 and decimals to 2.
Example 4: I want to mint a stablecoin with a total supply of 10B and divisible up to 3 decimals positions.
➥ Set the asset total to 10B * 103 and decimals to 3.


Whitelisted (Immutable)
81
Parameter
Description
Required
DefaultFrozen
Set True to enable asset whitelisting.
YES
Example 1: I want to mint a whitelisted asset and whitelist users.
➥ Set the asset default frozen to True then use the Freeze Address to add (or remove) users to the asset’s whitelist. See RBAC section.


Role-based Access Control (RBAC)
82
Parameter
Description
Manager Address
The only account that can re-configure any RBAC address (if active) or destroy an asset.
Reserve Address
Non-minted supply reserve (has no special administrative powers). Default: Creator Account. Assets transferred from Reserve Account are minted and accounted as circulating supply.
Freeze Address
If active, the Freeze Address is allowed to whitelist or blacklist users freezing (or unfreezing) asset holdings for a specific accounts. When an account is frozen it cannot send or receive the frozen asset (but could still close-out the asset to the Creator Address).
Clawback Address
If active, the Clawback Account is allowed to transfer assets from and to any asset holder. Clawback Address is usually adopted to revoke assets from users (if active).
Built-in role based access control governance (regulatory frameworks compliance). 
Control roles could be re-configured or irreversibly deactivated.


ARC-3
Algorand Standard Asset Parameters Conventions for Fungible and Non-Fungible Tokens

83
Status: Final
Defines Fungible Tokens, Pure NFT, Fractional NFTs
Very comprehensive definition of NFT’s metadata (e.g. images, videos, audio tracks, etc.) and traits as JSON structure
Binding between the ASA and the JSON structure uploaded on external storage (e.g. IPFS, Arweave, etc.)
Circulating tokens: ~ 42,000
Generators: https://arc3.xyz/, https://app.algodesk.io/
Example: https://www.nftexplorer.app/asset/429087615



ARC-69
Community Algorand Standard Asset Parameters Conventions for Digital Media Tokens

84
Status: Living
Adopted both in art and games (https://algoseas.io/)
Simple and succinct definition of NFT’s metadata and traits as JSON structure. Allows tratits configuration after minting
Binding between the ASA and the JSON structure uploaded directly on-chain as transaction notefield
Circulating tokens: ~ 565,000 (most popular standard)
Generators: https://app.algodesk.io/
Example:  https://www.nftexplorer.app/asset/420625533



ARC-19
Templating of NFT ASA URLs for mutability

85
Status: Final
Has been adopted as building block of non-fungible-domain standard proposed by NFDomains
Makes use of ASA Reserve Address to update the NFT metadata binding over time.
Circulating tokens: ~ 26,000
Generators: https://app.nf.domains/
Example: https://app.nf.domains/name/john.algo



ARC-20 / ARC-18
Smart ASA / Royalty Enforcement Specification

86
Status: ARC-18 (Draft), ARC-20 (Draft)
Binds a native ASA with a Smart Contract creating a “Smart ASA”, useful whenever a decentralized transferability policy must be enforced on-chain (e.g. royalties, vesting, limited amount per day, etc.)
Allows ASA programmable full reconfigurability on the AVM (e.g. enforcing a rule to upgrade a trait of a NFT character in game, etc.) 
ARC-20 Reference Implementation
ARC-18 Reference Implementation (using Beaker)



87
Algorand Virtual Machine
Programming on Algorand






Cosimo Bassi
Solutions Architect at Algorand

cosimo.bassi@algorand.com


What’s a Smart Contract ?
89
Smart Contracts are deterministic programs through which complex decentralized trustless applications can be executed on the AVM.
The Algorand Virtual Machine is a Turing-complete secure execution environment that runs on Algorand consensus layer.
What’s the AVM ?


Algorand Virtual Machine purpose: approving or rejecting transactions’ effects on the blockchain according to Smart Contracts’ logic.
What the AVM actually does?
90
AVM approves transactions’ effects if and only if:
There is a single non-zero value on top of AVM’s stack;
AVM rejects transactions’ effects if and only if:
There is a single zero value on top of AVM’s stack;
There are multiple values on the AVM’s stack;
There is no value on the AVM’s stack;
[...]
[...]
[...]
[...]
[...]
STACK MACHINE


How the AVM works?
91
Suppose we want the AVM to check the following assertion:
1 + 2 = 3
[...]
[...]
[...]
[...]
[...]
STACK MACHINE


How the AVM works?
92
Suppose we want the AVM to check the following assertion:
1 + 2 = 3
1
[...]
[...]
[...]
[...]
STACK MACHINE
pushing first operand


How the AVM works?
93
Suppose we want the AVM to check the following assertion:
1 + 2 = 3
2
1
[...]
[...]
[...]
STACK MACHINE
pushing
second operand


How the AVM works?
94
Suppose we want the AVM to check the following assertion:
1 + 2 = 3
2
1
[...]
[...]
[...]
STACK MACHINE
applying
operator


How the AVM works?
95
Suppose we want the AVM to check the following assertion:
1 + 2 = 3
3
[...]
[...]
[...]
[...]
STACK MACHINE


How the AVM works?
96
Suppose we want the AVM to check the following assertion:
1 + 2 = 3
3
3
[...]
[...]
[...]
STACK MACHINE
pushing
last operand


How the AVM works?
97
Suppose we want the AVM to check the following assertion:
1 + 2 = 3
3
3
[...]
[...]
[...]
STACK MACHINE
applying
operator


How the AVM works?
98
Suppose we want the AVM to check the following assertion:
1 + 2 = 3
true
[...]
[...]
[...]
[...]
STACK MACHINE


AVM architecture
99
Sender
Receiver
Fee
FirstValid
LastValid
Amount
Lease
Note
TypeEnum
… 
[0]:    Bytes
[i]:    Bytes
[255]:  Bytes
TRANSACTION
TRANSACTION ARGS
[0]:  UInt64 / Bytes
[i]:  UInt64 / Bytes
[63]: UInt64 / Bytes
APP GLOBAL K/V PAIRS
[0]:  UInt64 / Bytes
[i]:  UInt64 / Bytes
[15]: UInt64 / Bytes
APP LOCAL K/V PAIRS
[0]:  UInt64/ Bytes
[i]:  UInt64/ Bytes
[15]: UInt64/ Bytes
[0]:  Bytes
[i]:  Bytes
[3]:  Bytes
[0]:  UInt64
[i]:  UInt64
[7]:  UInt64
APP IDs ARRAY
ACCOUNT ARRAY
APP ARG ARRAY
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
&&
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
txn Amount
int 42
==
txn Amount
int 77
==
||
&&
PROGRAM
[0]:    UInt64 / Bytes
[i]:    UInt64 / Bytes
[999]:  UInt64 / Bytes
STACK MACHINE
[0]:    UInt64 / Bytes
[i]:    UInt64 / Bytes
[255]:  UInt64 / Bytes
SCRATCH SPACE
[0]:  UInt64
[i]:  UInt64
[7]:  UInt64
ASSET ARRAY
Stateless properties
Stateful properties
Processing
Block Number
Block Timestamp
...
BLOCK GLOBAL VARS
ALGO / ASA Balance
...
...
ACCOUNT STATE VARS
Max Key + Value size: 128 bytes
[0]:  App ID / Box ID
[i]:  App ID / Box ID
[7]:  App ID / Box ID
BOX ARRAY
Bytes (32 kb per Box)

Unlimited number of Boxes
APP BOX STORAGE


NODE
COMPILERS
IDEs
How to program the AVM?
100
Algorand Virtual Machine (AVM)
TEAL
AVM Bytecode
PyTeal
TEAL
AVM Bytecode
Reach Lang
TEAL
AVM Bytecode
TEAL
AVM Bytecode
Languages...
...
...
...


101
ASC1Algorand Smart Contracts on Layer-1

AVM Modes
102
ASC1
Mode 1:
SMART SIGNATURE
(Stateless)
Mode 2:
SMART CONTRACTS
(Stateful)


Mode 1:
SMART SIGNATURE
(Stateless)
Stateless ASC1
103
ASC1
Mode 2:
APPLICATION
(Stateful)
Contract
Account
Application
Smart Signatures are programs whose logic governs transactions’ authorization.
Domain: transient properties
“Stateless ASC1 deal with assets’ spending approvals”
Delegated
Signature


Stateful ASC1
104
ASC1
Mode 1:
LOGIC SIGNATURE
(Stateless)
Contract
Account
Application
Delegated
Signature
Smart Contracts are programs whose logic reads and writes blockchain’s state, creates and submits transactions.
Domain: persistent properties
“Stateful ASC1 deal with accounts’ state changes”
Mode 2:
SMART CONTRACTS
(Stateful)


105
SMART SIGNATURESAuthorizing transactions through TEAL logic

Creating Smart Signature
106
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
&&
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
txn Amount
int 42
==
txn Amount
int 77
==
||
&&
PROGRAM
NODE
SMART SIGNATURE
CONTRACT PUBLIC ADDRESS
Compiled TEAL Max Size: 1000 bytes
OpCode Max Budget: 20.000


Contract Account
107
CONTRACT ACCOUNT

ASC1 PUBLIC ADDRESS
LOCAL STATE
STANDARD / MULTISIG
ACCOUNT
TRANSACTION
SMART SIGNATURE
STANDARD / MULTISIG
ACCOUNT
funds...
appends...
binding


Delegated Signature
108
STANDARD / MULTISIG
ACCOUNT
SMART SIGNATURE
DELEGATED SIGNATURE
TRANSACTION
STANDARD / MULTISIG
ACCOUNT
STANDARD / MULTISIG
ACCOUNT
signs...
appends...
PUBLIC ADDRESS
SECRET KEY
binding


109
SMART CONTRACTSDecentralized Applications on Algorand

Deploying Applications on chain
110
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
&&
submits...
APPROVAL PROGRAM
NODE
APPLICATION CALL
TRANSACTION
CREATE
B1
B2
B3
...
Br
BLOCKCHAIN
APPLICATION ID
Compiled TEAL Max Size: 2048 bytes (+3 Extra Pages)
OpCode Max Budget: 700 (x16 Atomic Calls)
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
CLEAR PROGRAM
The Approval Program is responsible for processing all application calls to the contract, with the exception of the Clear Call. This program is responsible for implementing most of the logic of an Application.
The Clear Program is used to handle accounts using the Clear Call to remove the smart contract from their balance record.
State Schema
The State Schema specifies the memory allocation of the application.


Application Minimum Balance requirements
111


Calling Applications
112
APPLICATION ID
GLOBAL STATE
uint64
bytes
APPLICATION CALL
TRANSACTION
NO-OP
APP USER ACCOUNT
Generic application calls to execute the Approval Program
APPROVAL PROGRAM
CLEAR PROGRAM
LOCAL STATE
uint64
bytes
APPLICATION CALL
TRANSACTION
OPTIN
Application call used by Accounts to participate in an Application enabling Local State usage.
APPLICATION CALL
TRANSACTION
UPDATE
APPLICATION CALL
TRANSACTION
DELETE
APPLICATION CALL
TRANSACTION
CLOSE-OUT
Application call used by Accounts to close out their participation in an Application. This call can fail based on the TEAL logic, preventing the account from removing the Local State.
APPLICATION CALL
TRANSACTION
CLEAR
Application call used by Accounts to close out their participation in an Application. This call will always remove the account’s Local State whether the program succeeds or fails.
Application call to update the application’s Programs
(if enabled)
Application call to delete the application
(if enabled)
APP ACCOUNT


Interacting with Applications
113
APPLICATION CALL
TRANSACTION
APPLICATION
(PROGRAM ON-CHAIN)
APP USER
ACCOUNT
EXTERNAL LOCAL STATE
APP USER
ACCOUNT 1
LOCAL STATE

KYC:    PENDING
APP USER
ACCOUNT 2
LOCAL STATE

KYC:    REJECTED
GLOBAL STATE

INTEREST RATE:    1%
INNER
TRANSACTION
Apps
Arguments
Assets
Accounts
LOG VALUE
EXTERNAL GLOBAL STATE

INTEREST RATE:    2%
Up to 256 Inner Transactions
per App Call
read / write
read / write
read only
read only
Application Call Arrays define the state context of the execution
With Inner Txns App can
transfer ALGOs,
interact with ASAs (create, opt-in, transfer, etc…),
interact with other Apps
(create, opt-in, call, etc…)
GROUP TRANSACTION

SCRATCH SPACE
read only
write


Contract 2 Contract interaction
114
APPLICATION

1
APPLICATION

2
APPLICATION

i
APPLICATION

7
APPLICATION

8
An application may not call itself, even indirectly. This is referred to as re-entrancy and is explicitly forbidden. 
An application may only call into other applications up to a stack depth of 8.
Inner App Call
Inner App Call
Inner App Call
Inner App Call


An application may issue up to 256 inner transactions to increase its budget (max budget of 179.2k!), but the max call budget is shared for all applications in the group.
Smart Contract Execution: op-code budget
The op-code budget is consumed during execution of every Algorand Smart Contract according to the op-code cost. In order for the evaluation to succeed, the budget must not exceed 700 points. Each App Call (also as Inner Transactions) provides an additional budget of 700 points to the whole execution.
115
BUDGET COSTLY
APPLICATION
KNOWN BUDGET TOP-UP APPLICATION
Inner
App Call
DISPOSABLE BUDGET TOP-UP APPLICATION
Inner
App Create/Delete


Smart Contract Interface: ABI
116
The ABI (Application Binary Interface) defines the encoding/decoding of data types and a standard for exposing and invoking methods in a Smart Contract. The specification is defined in ARC-4.
At a high level, the ABI allows contracts to define an API so clients know exactly what the Smart Contract is expecting to be passed (like a “Smart Contract Swagger”).


117
TEALAVM assembly-like language

Smart Signature Example
118
Suppose we want to develop a Smart Signature that approves a transaction if and only if:

is “Payment” type transaction;
the receiver is a specific “ADDR”;
fees are less or equal to “1000 microALGO”;
first argument is equal to “bianconiglio”;
amount is  equal to “42 ALGO”;
or amount is equal to “77 ALGO”;

Where do we start?


Smart Signature as “Transaction Observer”
119
Smart Signatures can be defined as a “transactions’ observers”: programs that meticulously check all fields in the transaction (or in a group of transactions) that intend to “approve” or “reject” based on TEAL logic.

To translate those 6 semantically defined example’s conditions into TEAL we need to check which transaction fields are going to be controlled by Smart Signature’s logic.



Let's start with the translation...


Translating conditions into TEAL…
120
is “Payment” type transaction;
txn TypeEnum
int 1
==
1


121
the receiver is a specific “ADDR”;
txn Receiver
addr AOC7...
==
2
Translating conditions into TEAL…


122
fees are less or equal to “1000 microALGO”;
txn Fee
int 1000
<=
3
Translating conditions into TEAL…


123
first argument is equal to “bianconiglio”;
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
4
Translating conditions into TEAL…


124
amount is  equal to “42 ALGO”;
txn Amount
int 42000000
==
5
Translating conditions into TEAL…


125
amount is  equal to “77 ALGO”;
txn Amount
int 77000000
==
6
Translating conditions into TEAL…


126
Logic connectors…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
STACK
[...]
[...]
[...]
1
2
3
4
5
6


127
Logic connectors…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
STACK
[...]
[...]
[...]
1
2
3
4
5
6
This is probably the most complex phase in TEAL programming, because you need to keep in mind the state of the stack.

This phase is drastically simplified with the use of PyTEAL, Python binding for TEAL, which automatically performs this concatenation, saving us the effort of thinking about the state of the stack.


128
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
[...]
[...]
[...]
[...]


129
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
1
STACK
[...]
[...]
[...]


130
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
1
[...]
[...]
[...]
STACK


131
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
[...]
[...]
[...]
[...]


132
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
STACK
1
[...]
AOC7...


133
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
STACK
1
AOC7...
AOC7...


134
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
1
AOC7...
AOC7...
STACK


135
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
1
[...]
[...]
[...]


136
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
1
[...]
[...]
[...]


137
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
[...]
[...]
[...]
[...]


138
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
STACK
1
[...]
1000


139
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
STACK
1
1000
1000


140
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
STACK
1
1000
1000


141
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
1
[...]
[...]
[...]


142
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
[...]
[...]
STACK
1
1
bianconiglio


143
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
[...]
STACK
1
bianconiglio
bianconiglio


144
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
[...]
STACK
1
bianconiglio
bianconiglio


145
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
1
[...]
[...]
1


146
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
1
[...]
[...]
1


147
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
1
[...]
[...]
[...]


148
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
1
[...]
[...]
[...]


149
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
[...]
[...]
[...]
[...]


150
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
42000000
STACK
1
[...]
[...]
[...]


151
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
42000000
42000000
STACK
[...]
[...]
1


152
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
42000000
42000000
[...]
[...]
1
STACK


153
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
1
STACK
1
[...]
[...]
[...]


154
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
42000000
STACK
1
[...]
1
[...]


155
Execution…
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
42000000
77000000
STACK
1
[...]
1


156
Execution…
[...]
1
1
42000000
77000000
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
STACK


157
Execution…
0
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
STACK
1
[...]
[...]
1


158
Execution…
0
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
STACK
1
[...]
[...]
1


159
Execution…
1
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
STACK
1
[...]
[...]
[...]


160
Execution…
1
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
STACK
1
[...]
[...]
[...]


161
Execution…
1
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
STACK
[...]
[...]
[...]
[...]


162
Conclusion…
1
txn TypeEnum
int 1
==
txn Receiver
addr AOC7...
==
&&
txn Fee
int 1000
<=
arg 0
byte base64 "YmlhbmNvbmlnbGlv"
==
&&
&&
txn Amount
int 42000000
==
txn Amount
int 77000000
==
||
&&
STACK
[...]
[...]
[...]
[...]
True


163
Smart Signature written in PyTEAL


164
PyTEAL
Writing Smart Contracts with Python



Jason Paulos
Senior Software Engineer at Algorand



Matteo Almanza
Blockchain Engineer at Algorand



What’s PyTEAL?
166
PyTEAL is a Python language binding for Algorand Virtual Machine.
PyTEAL allows Smart Contracts and Smart Signatures to be written in Python and then compiled to TEAL.


167
It’s easier with PyTEAL!
TEAL Source Code
txn Receiver
addr AOC7...
==
txn Amount
int 1000
<=
&&
COMPILE...
AVM bytecode
PyTEAL Source Code
And(
Txn.Receiver == Addr(AOC7...),
    	Txn.Amount <= Int(1000),
)

TEAL Source Code
txn Receiver
addr AOC7...
==
txn Amount
int 1000
<=
&&
COMPILE...
COMPILE...
AVM bytecode


PyTEAL Basics - Intro
168
You’re writing Python code that produces TEAL code.
from pyteal import *

program = ... # a pyteal expression
teal_source = compileTeal(program, mode=Mode.Application, version=7)

>>> teal_source
"#pragma version 7\nintcblock 0 1\ntxn NumAppArgs\nintc_0 // 0\n==\nbnz main_l4\ntxna ApplicationArgs 0\npushbytes 0x90e75c9d..."



PyTEAL Basics - Intro
169
PyTEAL expressions represent an abstract syntax tree (AST)
# [...]
program = Seq(
   For(
  i.store(Int(0)),
  i.load() < Int(16),
  i.store(i.load() + Int(1)))
   .Do(
       App.globalPut(
Concat(Bytes("index"), Itob(i.load())),
Int(1))
   ),
   Approve(),
)
Seq
For
Approve
store
<
store
Do
…


PyTEAL Basics - Types (1/2)
170
Two basic types:
uint64
byte strings
i = Int(5)

x = Bytes("content")
y = Bytes(b"\x01\x02\x03")
z = Bytes("base16", "05")
Boolean? Logic ops on uints: 0 false, non zero true

PyTEAL Basics - Types (2/2)
171
Conversion between types
Itob - integer to bytes (8-byte big endian)
Btoi - bytes to integer
Itob(i) # produces the byte string 0x0000000000000005
Btoi(z) # produces the integer 5


PyTEAL Basics - Math operators
172
Math and logic operators (uint as boolean: 0 is false, non zero is true)
i = Int(10)
j = i * Int(2) + Int(1) # => Add(Mul(i, Int(2)), Int(1))
k = And(Int(1), Or(Int(1), Int(0)))
	
	
	# Expressions are not optimized
	z = j * j # => Mul(Add(Mul(i, Int(2)), Int(1)), Add(Mul(i, Int(2)), Int(1)))
Everything is an expression, and stay so

PyTEAL Basics - Byte string manipulation
173
Byte string manipulation
x = Bytes("content")
y = Concat(Bytes("example "), x) # "example content"
z = Substring(y, Int(2), Len(y)) # "ample content"


PyTEAL Basics - Crypto utilities
174
Built-in crypto utilities
h_sha256 = Sha256(z)
h_sha512_256 = Sha512_256(z)
h_keccak = Keccak256(z)


PyTEAL Basics - Fields (1/3)
175
Fields from the current transaction
Txn.sender()
Txn.accounts.length()
Txn.application_args.length()
Txn.accounts[1]
Txn.application_args[0]
Txn.group_index()


PyTEAL Basics - Fields (2/3)
176
Fields from transactions in the current atomic group
Gtxn[0].sender()
Gtxn[Txn.group_index() - Int(1)].sender()
Gtxn[Txn.group_index() - Int(1)].accounts[2]

# Gtxn (and other globals) indexes can be both (python) int and expr

Some objects can be accessed both with immediates and stack based expr (different opcodes beneath)

PyTEAL Basics - Fields (3/3)
177
Fields from execution context
Global.group_size()
Global.round() # current round number
Global.latest_timestamp() # UNIX timestamp of last round


PyTEAL Basics - Logs
178
Log publicly viewable messages to the chain
	Log(Bytes("message"))



PyTEAL Basics - State (1/2)
179
Global - one instance per application
App.globalPut(Bytes("status"), Bytes("active")) # write to global key "status"

status = App.globalGet(Bytes("status")) # read global key "status"

App.globalDel(Bytes("status")) # delete global key "status"

# Can also access global state of other smart contracts – no secrets


PyTEAL Basics - State (1.5/2)
180
Global - one instance per application
# Remember that we are building expressions, not fetching values

old_status = App.globalGet(Bytes("status")) # read global key "status"
program = Seq(
	# Update status
App.globalPut(Bytes("status"), Bytes("frozen")), # write to global key "status"
# Check if was previously active
If(old_status != Bytes("frozen")).Then(
Log(Bytes("Was active")) # <= Will never execute 
)
)



PyTEAL Basics - State (2/2)
181
Local - one instance per opted-in account per application
App.localPut(Txn.sender(), Bytes("level"), Int(1)) # write to sender's local key "level"
App.localPut(Txn.accounts[1], Bytes("level"), Int(2))  # write to other account's local key "level"

sender_level = App.localGet(Txn.sender(), Bytes("level"))  # read from sender's local key "level"

App.localDel(Txn.sender(), Bytes("level"))  # delete sender's local key "level"


PyTEAL Basics - Control Flow (1/5)
182
Approve the transaction and immediately exit
Approve()
Reject the transaction and immediately exit
Reject()


PyTEAL Basics - Control Flow (2/5)
183
Multiple expressions can be joined into a sequence
program = Seq(
   App.globalPut(Bytes("count"), App.globalGet(Bytes("count")) + Int(1)),
   Approve()
)


PyTEAL Basics - Control Flow (3/5)
184
Basic conditions can be expressed with If, Then, Else, ElseIf
program = Seq(
   If(App.globalGet(Bytes("count")) == Int(100))
   .Then(
       App.globalPut(Bytes("100th caller"), Txn.sender())
   )
   .Else(
       App.globalPut(Bytes("not 100th caller"), Txn.sender())
   ),
   App.globalPut(Bytes("count"), App.globalGet(Bytes("count")) + Int(1)),
   Approve(),
)


PyTEAL Basics - Control Flow (4/5)
185
Larger conditions can be expressed with Cond
program = Cond(
   [Txn.application_id() == Int(0), on_create],
   [Txn.on_completion() == OnComplete.UpdateApplication, on_update],
   [Txn.on_completion() == OnComplete.DeleteApplication, on_delete],
   [Txn.on_completion() == OnComplete.OptIn, on_opt_in],
   [Txn.on_completion() == OnComplete.CloseOut, on_close_out],
   [Txn.on_completion() == OnComplete.NoOp, on_noop],
   # error if no conditions are met
)


PyTEAL Basics - Control Flow (5/5)
186
Loops can be expressed with For and While
i = ScratchVar(TealType.uint64)

on_create = Seq(
   For(i.store(Int(0)), i.load() < Int(16), i.store(i.load() + Int(1)))
   .Do(
       App.globalPut(Concat(Bytes("index"), Itob(i.load())), Int(1))
   ),
   Approve(),
)


PyTEAL Basics - Subroutines (1/2)
187
Sections of code can be put into subroutines (Python decorators)
@Subroutine(TealType.uint64)
def isEven(i):
   return i % Int(2) == Int(0)

App.globalPut(Bytes("value_is_even"), isEven(Int(10)))


PyTEAL Basics - Subroutines (2/2)
188
Recursion is allowed
@Subroutine(TealType.uint64)
def recursiveIsEven(i):
   return (
       If(i == Int(0))
       .Then(Int(1))
       .ElseIf(i == Int(1))
       .Then(Int(0))
       .Else(recursiveIsEven(i - Int(2)))
   )


PyTEAL Basics - Inner Transactions (1/3)
189
Every application has control of an account
Global.current_application_address()


PyTEAL Basics - Inner Transactions (2/3)
190
Applications can send transactions from this account – even to other Apps
Limitation: no reentrancy
Seq(
   InnerTxnBuilder.Begin(),
   InnerTxnBuilder.SetFields(
       {
           TxnField.type_enum: TxnType.Payment,
           TxnField.receiver: Txn.sender(),
           TxnField.amount: Int(1_000_000),
       }
   ),
   InnerTxnBuilder.Submit() # send 1 Algo from the app account to the transaction sender
)


PyTEAL Basics - Inner Transactions (3/3)
191
appAddr = Global.current_application_address()
Seq(
   InnerTxnBuilder.Begin(),
   InnerTxnBuilder.SetFields(
       {
           TxnField.type_enum: TxnType.AssetConfig,
           TxnField.config_asset_name: Bytes("PyTEAL Coin"),
           TxnField.config_asset_unit_name: Bytes("PyTEAL"),
           TxnField.config_asset_url: Bytes("https://pyteal.readthedocs.io/"),
           TxnField.config_asset_decimals: Int(6),
           TxnField.config_asset_total: Int(800_000_000),
           TxnField.config_asset_manager: appAddr,
       }
   ),
   InnerTxnBuilder.Submit(), # create a PyTEAL Coin asset
   App.globalPut(Bytes("PyTealCoinId"), InnerTxn.created_asset_id()) # remember the asset ID
)


PyTEAL Basics - Other operations
192
See docs at https://pyteal.readthedocs.io/en/stable/overview.html

Wide math
Balances, assets holding and parameters
JSON (limited) parsing
…



A pythonic Algorand stack
193
Algorand Python SDK
PyTEAL & Beaker
PyTest for Smart Contracts unit-tests and e2e-tests
TEAL Debugger
Algorand Sandbox Docker in dev mode
PyCharm IDE & AlgoDEA plug-in


“Zero to Hero PyTEAL” crash course
194
Join and learn in 12 lessons!


195
Algorand ABI
Writing ABI Compliant Smart Contracts with PyTEAL





Stefano De Angelis
Research Solutions Architect at Algorand

stefano@algorand.com


What is an ABI?
197
An ABI (Application Binary Interface) is an interface between two binary program modules, one of which is at the level of machine code. The interface defines the convention of how data is encoded/decoded into/out of the machine code via computational routines.


Algorand ABI is the interface that defines a standard on how to call Algorand Smart Contracts, the encoding/decoding of Application Call arguments and the return values.

ARC4 is the specification for Algorand ABI. It defines a standard approach to call smart contract methods and describes the ABI interface description object. It is a human readable and machine readable JSON file showing the methods of a smart contracts, the required input parameters and the return values.
Algorand ABI
198
ARC: Algorand Request for Comments is a collection of specifications (collected by the algorand Foundation) that talk about standardisation of development approaches. The community discuss on ARC and eventually reach an agreement making the ARC standardised.Example: I write a smart contract with a method that takes a string as a parameter. That parameter must be somehow encoded in TEAL before calling the method. So for an external client, I need to instruct them on how to call my smart contract method properly, and how to encode parameter.

Why an Algorand ABI?
Smart Contract developers can publish the interface JSON file before deploying the application on the blockchain.
Client applications just need to read the interface JSON file and properly call the smart contract methods and process return values.
—--------------
Algorand Blockchain
—--------------
Smart Contract A
Smart Contract B
ABI Interface Repository
{    …}
ABI Interface JSON A
ABI Interface JSON B
{    …}
dApp1
dApp2
Wallet
Read
Invoke method
199
The Algorand ABI facilitates the interaction between client applications and smart contracts. 

ABI Interface JSON File (1/3)
The ABI Interface JSON file is composed by three distinct JSON types called Method, Interface and Contract.

A Method description defines a method with the expected arguments and return type.
200

ABI Interface JSON File (2/3)
An Interface description defines a collection of Methods. It is a way to represent the set of methods required to implement an ARC4 compliant Smart Contract. It can be extended with other methods.
201

ABI Interface JSON File (3/3)
A Contract description defines a specific Smart Contract that currently exists on the blockchain, and specifies all the methods the contract implements. It is an implementation of an Interface.
202

ARC4 ABI Methods standard
The ARC4 defines a method signature as a way to identify a smart contract method. It is expressed as method name, arguments types, return type.
add(uint64, uint64)uint128

The method selector is the first 4 bytes of the hash of a signature
SHA-512/256 hash (in hex): 8aa3b61f0f1965c3a1cbf…70184ff89dc114e877b1753254a
Method selector (in hex): 8aa3b61f

The method selector to be specified as the first argument of an Application Call transaction. The smart contract must route to the corresponding method matching the selector.
203
Method signatures could be very long as well as their hashed value. To optimise the space and comply with the limit of 128 bytes per arg, ARC4 introduced method selectors.

PyTEAL ABI - Intro
PyTEAL can now support the implementation of ARC4 ABI Standardised applications by introducing the following new features:

Encoding/decoding basic types;
Encoding/decoding reference types;
Encoding/decoding transaction types;
ABI methods standard;
ABI Interface JSON File.
204

PyTEAL ABI - Basic Types
AVM stack types limited to uint64, bytes. PyTEAL ABI supports new basic types whose encoding is standardized to AVM basic types.
PyTeal Type
Description
abi.UintN
An N-bit unsigned integer, where 8 <= N <= 64
abi.Bool
A boolean value that can be either 0 or 1
abi.Byte
An 8-bit unsigned integer used to indicate non-numeric data
abi.StaticArray[T,N]
A fixed-length array of T with N elements
abi.Address
A 32-byte Algorand address. This is an alias for abi.StaticArray[abi.Byte, Literal[32]]
abi.StaticBytes[N]
A fixed-length array with N elements of abi.Byte
abi.DynamicArray[T]
A variable-length array of T
abi.DynamicBytes
A variable length array of abi.Byte
abi.String
A variable-length byte array assuming UTF-8 content. This is an alias for abi.DynamicArray[abi.Byte]
abi.TupleN, abi.NamedTuple
A tuple of multiple types, where 0 <= N <= 5
205

PyTEAL ABI - Setting Values
To create and instantiate an ABI Type we have the abi.make() method. 
All Basic Types have a set() method which can be used to assign a value. 
my_address = abi.make(abi.Address)
my_bool = abi.make(abi.Bool)
my_uint64 = abi.make(abi.Uint64)
my_tuple = abi.make(abi.Tuple3[abi.Address, abi.Bool, abi.Uint64]

program = Seq(
   my_address.set(Txn.sender()),
   my_bool.set(Txn.fee() == Int(0)),
   my_uint64.set(5000),
   my_tuple.set(my_address, my_bool, my_uint64)
)
206

PyTEAL ABI - Getting Values
Basic types have a get() method which can be used to extract that value. 
	my_address.get() # Returns the 32-byte Algorand address of Txn.sender()
207

PyTEAL ABI - Working with NamedTuples
A NamedTuple is a PyTEAL Tuple that has named elements.
class User(abi.NamedTuple):
   address: abi.Field[abi.Address]
   balance: abi.Field[abi.Uint64]

my_user = User()

program = Seq(
   my_user.set(Txn.sender(), 5000),
   Approve(),
)
208

PyTEAL ABI - Reference Types
Blockchain entities passed to the AVM within the foreign arrays of the method call.
PyTeal Type
Description
abi.Account
Represents an account stored in the Txn.accounts array
abi.Asset
Represents an asset stored in the Txn.assets array
abi.Application
Represents an application stored in the Txn.applications array
209

PyTEAL ABI - Working with Reference Types (1/2)
Reference types expose methods to obtain the ID of the object referenced and to access that object’s parameters
@Subroutine(TealType.none)
def check_ref_values(my_user: abi.Account, my_asset: abi.Asset, my_app: abi.Application):
   return Assert(
   	my_user.address() == my_app.params().creator_address(),
   	my_asset.asset_id() == Int(5),
   )

210

PyTEAL ABI - Working with Reference Types (2/2)
Asset holding properties can be accessed using reference types
@Subroutine(TealType.none)
def ensure_asset_balance_is_nonzero(my_user: abi.Account, my_asset: abi.Asset):
   return Assert(
my_user.asset_holding(my_asset).balance() > Int(0)),
   )

211

PyTEAL ABI - Transaction Types
Transaction objects which are part of the same group of a method call. 
A method may have multiple Transaction Type arguments, in which case they must appear in the same order as the method’s arguments immediately before the method call.
PyTeal Type
Description
abi.Transaction
A catch-all for any transaction type
abi.PaymentTransaction
A payment transaction
abi.KeyRegisterTransaction
A key registration transaction
abi.AssetConfigTransaction
An asset configuration transaction
abi.AssetTransferTransaction
An asset transfer transaction
abi.AssetFreezeTransaction
An asset freeze transaction
abi.ApplicationCallTransaction
An application call transaction
212

PyTEAL ABI - Working with Transaction Types (1/2)
Get the absolute group index of a specific transaction in the group
@Subroutine(TealType.none)
def handle_txn_args(
   any_txn: abi.Transaction, 
   pay: abi.PaymentTransaction,
   axfer: abi.AssetTransferTransaction):
   return Assert(
       any_txn.index() == Txn.group_index() - Int(3),
       pay.index() == Txn.group_index() - Int(2),
       axfer.index() == Txn.group_index() - Int(1),
   )

213

PyTEAL ABI - Working with Transaction Types (2/2)
Transaction Types expose a get() method which can be used to access fields from a transaction in the group
@Subroutine(TealType.none)
def check_txn(pay: abi.PaymentTransaction, sender: abi.Account):
   return Assert(
       pay.get().sender() == sender().address(),
       pay.get().receiver() == Global.current_application_address(),
   )

214

PyTEAL ABI - Subroutines
Subroutines can now return ABI values using the ABIReturnSubroutine decorator. The output keyword is now used to store the return value
@ABIReturnSubroutine
def get_account_balance(account: abi.Account, *, output: abi.Uint64) -> Expr:
   return Seq(
      (balance := abi.Uint64()).set(App.localGet(account.get(), Bytes("balance")),
      output.set(balance),      
   )

215

PyTEAL ABI - ARC4 Program
ABI Programs respond to two specific subtypes of application call transactions:
Method calls: which encode a specific method to be called and the method arguments
Bare app calls: which have no arguments and no return values

ARC4 Program
Router
Bare Calls
Methods
Subroutines
BARE CALL
TRANSACTION
Application call without arguments or return value. This is suited for on completion actions such as optin, close out, update, ..
METHOD CALL
TRANSACTION
[args]
Application call to a method of the smart contract. This call may pass arguments to a method and produce a return value. The first argument of this call is the method selector.
encode/decode/log
BARE CALL
TRANSACTION
App Create
Application creation app call. It can invoke an on completion action like optin, close out, update, ..
216

PyTEAL ABI - Registering Bare Calls
A bare app call handler can be registered with the router. The actions of a bare call handler can be either an Expr or a Subroutine 
CallConfig options indicates whether the action is able to be called during an app creation, a non-creation, or either
router = Router(
   name = "ExampleApp",
   bare_calls = BareCallActions(
      no_op = OnCompleteAction(action=Approve(), call_config=CallConfig.CREATE),
      opt_in = OnCompleteAction(action=Approve(), call_config=CallConfig.CREATE),
      close_out = OnCompleteAction(action=Approve(), call_config=CallConfig.CALL),
      update_application = OnCompleteAction(
                           action=Assert(Txn.sender() == Global.creator_address()), 
                           call_config=CallConfig.CREATE),
      delete_application = OnCompleteAction(action=Reject(), call_config=CallConfig.CALL),
   )
)
217

PyTEAL ABI - Registering Methods
A method decorator placed on top of the method subroutine can be used to register that method with the application router
CallConfig options can be specified within the decorator directly

  
@router.method(no_op=CallConfig.CALL, opt_in=CallConfig.CALL)
def my_method(a: abi.Uint64, b: abi.Uint64):
   return Seq(
      ...
   )
218

Nice, we finally know how to implement ARC4 programs! Uhm?
219

PyTEAL ABI - Compiling ARC4 Programs
The PyTEAL router object provides the compile_program() method to compile an ARC4 program into TEAL code.
This method generates the approval and clear state programs, along with an auto-generated Contract object which represents the contract interface! 
router = ...

approval_program, clear_state_program, contract = router.compile_program(
   version=6, optimize=OptimizeOptions(scratch_slots=True))

with.open("example.json", "w") as f:
   f.write(json.dumps(contract.dictify(), indent=4))
220

Pump my JSON: docstrings!
221

Pump my JSON: docstrings!
222

PyTEAL ABI - Calling an ARC4 Program (1/2)
ARC4 programs can be called of-chain with the SDKs





We can also use the goal CLI
Atomic Transaction Composer is an SDK utility to construct transactions,  transaction groups, and ABI method calls with the functions addTransaction() and addMethodCall()
Bare calls can be invoked with either goal app create or goal app <action> commands, where actions are optin, closeout, clear, update, or delete.
Method calls can be triggered via the goal app method command
223

ARC4 programs can be also called on-chain with a contrat-to-contract call
PyTEAL ABI - Calling an ARC4 Program (2/2)
Inner transactions can invoke other applications’ ABI methods using the Inner Transaction Builder utility with the ExecuteMethodCall() function
InnerTxnBuilder.ExecuteMethodCall(
   app_id=56,
   method_signature="add(uint64,uint64)uint128",
   args=[5, 8],
)
224

AlgoBank Demo!
AlgoBank is your first ARC4 Program.

It acts as a escrow for users’ funds. It exposes three ABI methods
deposit(): Deposit some funds in the AlgoBank;
getBalance(): Retrieve the user’s funds locked in;
withdraw(): Claim back funds from the deposit

Deployment environment:
Algorand Sandbox: Dockerized private network!
DappFlow: Algorand blockchain explorer
225

226
Beaker
Algorand dApp Has Never Been Easier





Chris Kim
Developer Advocate at Algorand

chris.kim@algorand.com


PyTeal, SDK may feel…
Unfamiliar
Complex
Overwhelming 


Note: share my experience. I found it difficult. It may feel this way. Going to show you how to do this easier 



Algorand dApp Architecture
show diagram of full dapp with frontend. compare with normal web app. 

today we will learn how to write and deploy your smart contract with Beaker and learn how to interact with it with Algorand Python SDK

Frontend
Web Server
Database
Web2 App Architecture
What normal web app looks like

TODO:

below frontend, put user icon 

Algorand SDK
Frontend
Web Server
Database
Algorand Dapp Architecture
Algorand
Smart contract
AVM
Smart contract
Algorand SDK
What Algorand dApp would look like
Some may not even need a database and web server. Direct interaction with Algorand blockchain. 

sdk go to web server 

signing transactions

TODO:

make the web2 parts stay the same as previous slide and just add in the new parts. 

add user and wallet (key icon) 

add toolbox icon for SDK 







key management 
let customer take care of it (wallets pera, myalgo, ..)
let server handle it. (need to encrypt)
or have custodial services like securitize



web server
serve all javascript to client

node server

Today we will learn

Introducing Beaker: The Way dApp
development should be
talk about PPoS, carbon negative, solved blockchain trilemma, built by Silvio Micali, a turing awards winner

Talk about AVM, why Algorand chose to create its own virtual machine. 

Python smart contract framework 

Code Organization (PyTeal)
Deploy/ Call (Algorand SDK)
Debugging
In short, it handles all the heavy lifting for you


Let’s see a direct comparison
https://github.com/algorand-devrel/beaker-calculator




Bare Pyteal

Smart contract code is unfamiliar
Need to manually define helper functions
Frontend setup is lengthy 

Beaker

Smart Contract organization is familiar
helper methods defined for you
Easier to deploy/call contract 
Comparison Recap
recap of the comparison 

Frontend
Web Server
Database
Algorand Dapp Architecture
Algorand
Algorand SDK
Smart contract
AVM
Smart contract
Algorand SDK
Smart contract
What Algorand dApp would look like
Some may not even need a database and web server. Direct interaction with Algorand blockchain. 

sdk go to web server 

signing transactions

TODO:
key management 
let customer take care of it (wallets pera, myalgo, ..)
let server handle it. (need to encrypt)
or have custodial services like securitize



web server
serve all javascript to client

node server

Today we will learn

Testing
Application Class
Application Client
Sandbox
State
Decorators
Smart Contract 
Deploy/Call
Beaker Components


Developer Environment Setup

Sandbox


Pyteal


Python Algorand SDK


Beaker

git clone https://github.com/algorand/sandbox.git
Packages to Install

Sandbox
Packages to Install
Beaker
Python SDK
PyTeal

Launch Sandbox / Git Clone



Create Virtual Environment



install All Required Packages 
Beaker Starter Kit
python3 venv venv
source ./venv/bin/activate
 
pip install -r requirements.txt
./sandbox up dev
git clone [beaker-starter-kit url]

Beaker: Smart Contract (PyTeal)

Testing
Application Client
Sandbox
Application Class
State
Handlers
Smart Contract 
Deploy/Call
Beaker Components

Application Class
State
Decorators
Smart Contract 

Testing
Application Client
Sandbox
Application Class
State
Handlers
Smart Contract 
Deploy/Call
Beaker Components

State
Decorators
Application Class
Smart Contract 

Application Class

Base class that all Beaker Applications should inherit from


Included logic 
Detect State Variables
OnComplete methods 
ABI Methods
internal subroutines
Abstraction = Simple Code

Testing
Application Client
Sandbox
Application Class
State
Handlers
Smart Contract 
Deploy/Call
Beaker Components

Application Class
Decorators
State
Smart Contract 

 Application(Global) State

Use Final typing construct that prevents re-assigning of the variable name as good practice

 Application(Global) State

Specify state characteristics here:
stack_type
key (optional)
default (optional)
static (optional)
descr (optional)
ABI json File

Specify state characteristics here:
stack_type
max_keys
key_gen (optional)
descr (optional)
 Application(Global) State

ABI json File

 Account(Local) State

Specify state characteristics here:
stack_type
key (optional)
default (optional)
static (optional)
descr (optional)

 Account(Local) State

Specify state characteristics here:
stack_type
max_keys
key_gen (optional)
descr (optional)

Testing
Application Client
Sandbox
Application Class
State
Handlers
Smart Contract 
Deploy/Call
Beaker Components

Application Class
State
Decorators
Smart Contract 

Decorators

@external

expose methods as ABI methods

automatically add the method to router
@internal

Used internally in the contract
Can access state variables

OnComplete externals

create
opt_in
delete
update
clear_state
close_out
Support Authorization to only allow certain accounts to execute the method

Decorators: @external

expose methods as ABI methods

automatically add the method to router

Decorators: @internal

returns Tealtype uint64

Not exposed to ABI

Decorators: @internal

Access internal methods like this

useful for repeated complex computation 

Decorators: OnComplete Externals

Available OnComplete Externals
create
opt_in
delete
update
clear_state
close_out

Decorators: Bare Externals

Only creator of the contract can call this method
Authorize accounts that hold certain tokens
Authorize account opted in

Smart Contract Recap


Application Class

Base class that Beaker Apps inherit from
Provide Basic functionalities
State

Application = Global
Account = Local
Exposed to ABI


Decorators

@external
@internal
OnComplete Externals
Authorization

Beaker: Deploy / Call Smart Contract
Don’t go too deep with ABI since Beaker does it automatically for you. 

Testing
Application Client
Sandbox
Application Class
State
Handlers
Smart Contract 
Deploy/Call
Beaker components

Application Client
Deploy/Call
Sandbox
Testing

Sandbox

Sandbox

Sandbox

Application Client

Application Client
Convenient way to interact with your smart contract 
Saving 750 lines of code!

Application Client


No more manually
creating transaction
signing transaction
submitting transaction
waiting for confirmation

Application client handles it for you



Recap


Sandbox

Easily set up testing with helper methods that:
create algod client 
get list of sandbox accounts
and more

Application Client


Provides over 20 helper methods you can leverage to easily deploy / call your smart contract



Complete 
RSVP App
Create Break points and run the code 

Create RSVP Event
Guest RSVP
Guest Check in
Guest Refund
Funds Withdrawal
Event Delete 
RSVP Features




Algorand dApp Architecture
What Beaker is
Complete RSVP Example
What Did We Learn Today?




Beaker is Amazing

Algodevs Resources
FOLLOW ME!

Thanks to the contributors!

Cosimo Bassi
Jason Paulos
Pietro Grassano
Matteo Almanza
Stefano De Angelis
Chris Kim