1. Introduction to Tezos & Tezos
Tools
https://github.com/tezos-contrib/developers-presentation
2. Tezos recap, facts & figures
- The native token is called tez
- Proof of Stake, validators in Tezos are referred to as bakers
- “Liquid proof of stake”
- Baker status is permissionless, requires 8000 tez staked
- Accounts can delegate their holding to bakers
- On-chain governance
- Upgradeable, typically every 3 months there is a new version of the protocol
- Octez, the reference tezos node implementation is built in OCaml
- Strong Functional Programming culture
3. Tezos recap, facts & figures
- Tezos accounts can be implicit or contract accounts
- Smart contract accounts are governed by code
- The Michelson VM is a strongly typed stack-based VM
- Contracts are strongly typed: storage, call parameters
- Address prefix of KT1
- Implicit accounts are bound to a signing key (‘external’ accounts in Ethereum)
- 3 elliptic curves supported, address prefix shows key type
- tz1 = ed25519, tz2 = Secp256k1, tz3=NIST P256
- Are treated as contracts with storage type and call parameter type of ‘unit’
(empty type)
4. Tezos recap, facts & figures
- 30s blocktime (subject to change)
- Blocks and transactions are constrained by size and ‘gas’
- Transactions are batched by default (‘operation groups’)
- A single transaction is a batch of 1
- Allows for atomicity of connected / interdependent operations
- Transaction fee structure
- Transaction fee (minimum fee as function of size and gas cost, plus ‘tip’), goes
to baker
- Storage fee, burned
5. Tezos components we are going to talk about
- the node
- smart contract languages CameLIGO and SmartPy
- javascript library Taquito
- python library PyTezos
- The FA1.2 and FA2 token standards
6. The node
- Relatively easy to run oneself--hardware requirements are low
- There are a variety of public nodes
- List in the repository for this presentation
- Unfortunately, no commercial public infrastructure with QoS (like Infura) is available
- There are multiple public testnets
- New testnet is set up for each protocol version
- Testnets for the next version of the protocol and current version are maintained
- Flextesa: local test chain for quick developer testing
- Uses full node implementation
- Dockerized version available for simple deployment
7. RPC API and the command line client
- Chain functionality is exposed as an HTTP REST API
- RPC messages are in JSON format
- It is plain HTTP, and does not follow the ‘JSON-RPC’ protocol standard
- Access to different APIs is controllable in node configuration
- The ‘tezos-client’ tool
- Command line tool for interacting with a Tezos node
- Exposes the full RPC API to the command line
- Can be a bit fiddly (especially with escaping characters in a shell)
- But often the most straightforward way to interact
- Supports Ledger hardware wallets
8. Test Networks
- You don’t want to do testing on the main network (called ‘mainnet’)
- There is a new test network for every Tezos protocol upgrade
- Testnets don’t live very long (~9 mo)
- Lightweight to run a local node
- Onboarding onto a testnet:
- Find a public node, or set up a local node connected to an active testnet
- Obtain free testnet tez from a ‘faucet’ (https://testnets.xyz)
- Don’t forget to configure your tools to use the testnet
9. Smart contracts on Tezos
- Michelson VM
- Strongly typed
- Stack based
- Stack of typed objects
- Operations can unpack or pack complex types
- Functional features
- Lambda as atomic type (parametric, with input and output types)
- A smart contract is defined by
- Storage type
- Call parameter type
- Code - pure function
- Input is storage type and call parameter type
- Output is storage type and a list of operations
10. Smart contracts on Tezos
- Calling a smart contract
- Via ‘Transaction’ operation
- May transfer tez
- Includes a call parameter
- (has to be ‘unit’ - empty type - when transferring to implicit address)
- Entrypoints
- Different contract functions are defined through an option type
- Eg. ‘add(nat) or subtract(nat)’
- Options can be nested (eg. admin functions under ‘admin’)
- Tezos offers a shorthand to call any uniquely named option as an ‘entrypoint’
- Eg. ‘%add(12n)’
- Contract interoperation is asynchronous
- Via ‘operations’ returned from running a contract function
11. Digression: what belongs on chain?
- Why you shouldn’t store data on the blockchain
- It’s really expensive to store data on the blockchain.
- 0.001 tez/byte -> ~ $2k/Megabyte
- Sometimes it’s illegal (GDPR)
- Unsalted hash of sensitive data is sensitive
- Cyphertext of sensitive data is sensitive
- ‘Anchoring’ data
- Store the data appropriately (own server or IPFS) along with a salt value
- Generate a salted hash of the data
- Write the salted hash onto the chain as ‘proof of existence’ of the data
- The blockchain just records transactionality
- Eg. stores ownership records, not the thing which is owned
12. Digression: what belongs on chain?
- ‘If 100 lines of code off-chain can save 1 line of code on-chain, I’d consider that a
good tradeoff’ - Arthur Breitman
- Code on-chain is
- Expensive and slow
- Cannot be changed (*)
- Designing a distributed application involves
- finding the absolute minimum required functionality that has to be on-chain
- while maintaining required trust characteristics
- A smart contract should not try to do an indexer’s job
- On-chain accessibility of information is only needed if the smart contract logic
needs it
13. Coding in Michelson?
- Michelson is theoretically human readable
- In the early days of Tezos, it was the preferred way of coding
- It’s extremely fiddly to anything complex by hand
- One should still strive to be conversant in it
https://tezos.gitlab.io/michelson-reference/
parameter unit;
storage unit;
code {CDR; NIL operation; PAIR};
14. CameLIGO
- A member of the LIGO language family
- LIGO is a high level language with functional elements that compiles to Michelson
- The compiler offers good code optimization and increasingly good error handling
- Built-in tools in the compiler to facilitate unit testing
- Other members of the family include PascaLigo and JsLigo
- The CameLigo syntax is based on ML (one of the first functional languages)
- Looks like OCaml, the native language of the node
- CameLigo is our favourite of the Tezos languages.
- The most mature of the LIGO language family
- A good mesh with the internal logic of Tezos and Michelson
- The compiler produces the best-optimised code of all the languages.
https://ligolang.org/
15. SmartPy
- Everyone knows Python
- SmartPy is implemented as a Python library
- Meta-programming language
- Running the Python code outputs Michelson code
- Python flow control structures are executed at compile time
- There are special flow control structures to control contract execution
- Very popular
- Has its own Michelson VM, so unit testing is excellent
- Great community support
- Despite its popularity, it has some issues
- Python is weakly typed, which is at odds with strongly typed Michelson
- Optimisation is not as good as CameLIGO (this may be a controversial opinion)
https://smartpy.io/
18. Deploying a contract
- When we deploy a contract we do several things
- We upload the contract to the chain (creating an instance under a KT1
address)
- We may transfer tez to the contract if it needs it for operation
- We initialize the storage to something appropriate
- We pay for
- The origination operation
- The on-chain storage used by the code and the initial storage
- We obtain a contract identifier (address), which has a ‘KT1’ prefix
- The address of an originated contract is deterministic
- It depends on the hash of the origination transaction
22. Taquito
- Is the Javascript SDK for Tezos
- The most widely used Tezos SDK
- The most tested and reliable Tezos SDK
- It was written in Typescript
- Wide-ranging functionality
- Almost anything one can do with a Tezos node can be done in Taquito
- It supports contract interactions, and views
- Integrated with Tezos Domains, the de-facto standard Tezos naming system
- Supports various wallet / signer types
- In-memory wallets (especially good for serverside)
- Wallet interactions with...
23. Beacon
- Beacon is a standard for connecting to wallets in Tezos
- Wallets for Tezos include Kukai, Temple, Galleon…
- Kukai permits users to create wallets and sign transactions using their social
media login
- Temple is a traditional in-browser wallet (like Metamask) with hardware wallet
support
- There is sample code in the repo accompanying this presentation
- Use Beacon, it’s good for maintainability and compatibility
25. PyTezos
- PyTezos is the Python SDK for Tezos
- It has features which make it extremely convenient to access smart contracts
- It has a built in Michelson interpreter for testing
- Also supports views!
- The Python REPL is very convenient for interacting with contracts on-chain
- There are stability and reliability issues
27. Indexers
- Blockchain nodes’ purpose is to record transactions
- Querying them is slow and resource intensive
- They do not offer ways to search or query data effectively
- Eg. keys in a big_map cannot be enumerated
- An indexer is a piece of software that
- Connected to a node, continually indexes the chain
- Allows advanced queries to be quickly run on the indexed chain data
- ‘Whole chain’ indexers - public, can be self-hosted
- Better Call Dev https://better-call.dev/
- TzKT https://tzkt.io/
- You can inspect any contract, and their storage, operations and so on.
- Specialized indexers, only indexing specific data, eg. state of a contract
- Que-pasa https://github.com/tzConnectBerlin/que-pasa
28. Token standards on Tezos
- Tezos does not follow the EVM-based ERC-* token standards
- Local token standards exist
- FA1.2 (roughly equivalent to ERC-20)
- FA2 (roughly equivalent to ERC-1155)
- Multi-asset
- Non-fungible multi-asset
- (FA2.1 / FA3?) - On-chain views (a new protocol feature) to be integrated
- There is rarely any reason to manually reimplement a token standard
- There are existing implementations, some better than others
- We recommend: 0xheadalpha FA2 multi-asset
- Coming soon: new, better FA1.2 and FA2 implementations in LIGO
29. A fashionable use case: NFTS
- NFTs are tokens that represent ‘things’ rather than ‘amounts’
- Eg. a ticket to an event, or a piece of art
- NFTs on Tezos are implemented using the FA2 standard
- The FA2 standard defines an NFT-specific ledger type
- However, most existing implementations use the multi-asset ledger
- Structure of a typical NFT on Tezos
- The asset (eg. digital image) of the NFT is usually stored in IPFS
- The metadata refers to the asset, and is also usually stored in IPFS
- The token metadata on-chain refers to the metadata in IPFS
- Creating an NFT is called ‘minting’
- Minting is governed by rules defined in the token contract
- Tz Connect has a streamlined open source toolchain for minting NFTs
- https://github.com/tzConnectBerlin/peppermint
30. Further developer resources
For those who are new to Tezos development, the dev portal is a good place to start
https://developers.tezos.com/
Tacode, a p2p learning platform for Tezos teaches you how to build a Dapp on Tezos while
earning tez
https://tacode.dev
OpenTezos is an open-source wiki on all topics Tezos
https://opentezos.com/
A guide how to mint NFTs on Tezos and how to build a simple NFT platform
https://bit.ly/2U967s4
31. Further developer resources
A react provider for Dapps to easily setup connection to Beacon/Taquito wallets
Tezos Contrib Repository
Awesome list for Tezos
Tezos Contrib Repository
Tezos Stack Exchange is a useful resource to where you can see answers to technical
questions regarding Tezos
https://tezos.stackexchange.com/
If you do not find answers to your technical questions on the Tezos Stack Exchange, join the
Tezos Developers telegram channel and ask away
https://t.me/TezosDevelopers
