refonte OpenTezos / Blockchain 101

# refonte OpenTezos / Blockchain 101 --- id: stucture-of-a-blockchain disable_pagination: true title: Structure of a blockchain author: Nomadic Labs --- import NotificationBar from '../../../src/components/docs/NotificationBar'; At its heart, a blockchain is a piece of technology that enables a group of users to collectively share data, and has the following properties: - any user in the group has access to all of the data - any user can make changes to the data, as long they follow a set of rules - no small subset of users should be able to control the system This set of properties, associated with the right set of rules, can be leveraged for many use cases, including the secure storing and trading of cryptocurrencies and other digital assets. In this document, we present the basics of an architecture that enables these properties. We start by presenting the data structure of the blockchain, then present how users can work together to share this data and reach agreements on what changes are applied. ## Collectively storing read-only data, forever Imagine you are a member of a community of authors of digital content. You would like any member to be able to store their new content so that it stays available for any member forever, or at least as long as this community exists in some form. If you were in charge of solving this problem, how would you do it? Take a couple of minutes to think about it. ### Traditional approach A common solution is to use a cloud storage service, hosted by some large multi-national company. What could be the issues with this approach? This company may: - disappear or simply decide to stop offering this service - have techincal issues that make your data unavailable - decide that your content is against its new terms of service and delete it - prevent some members or entire countries from accessing the service - etc. Picking a company for your community's needs means having to *trust* that this company will continue offering the service to all your members without restrictions, for a very long time. This is what we call a *centralized approach*: a single entity is in charge of everything, and users need to trust that it won't unilaterally stop offering the service as you expect. Unfortunately, you can never fully trust a single entity. ### Decentralized approach Avoiding the issues that come with centralization means using *decentralization*: splitting the responsibility of the service between many entities, so that no small group of entities may prevent any user from using the service. How would you design a simple decentralized architecture to store the community's data and make it available? First, let's assume that many members of the community each have a single computer that they dedicate to this service. The community will have to agree on what software to run on these computers. We will call each running instance of this software a *node*. For a very basic architecture, we could have every node: - store all of the data from the community - be able to communicate with every other node (know each node's IP address). To **upload data**, for example a file, members would simply send that file and its name to every other node, that would then store it. To **download data**, a member could send a request for the file having a given name, to any of the nodes, and that node would send it to them. If for some reason the node is not available or rejects the request, they can simply try with another node. To **join the community**, a new user would just need to know the address of one node, request the list of all the other nodes, the list of all files, and start downloading their content. As long as one node is still running the software, and a member is connected to the internet, they will be able to download the content. ### Potential issues This simple approach presented above has a few issues. Can you think of some? Here are some of the main issues: - two members could use the same name for a file - as the community grows, the bandwith required to send files to every node becomes prohibitive - when nodes are temporarily unavailable, they will miss some files and become desynchronized - bad members could: - send the wrong data, for a given download request - saturate the node by sending too much data or too many requests Can you think of ways to improve our architecture to prevent these issues? ### Ensuring that nodes store/send the right data There is a risk that two members upload **different files with the same name**. If they start uploading these files to nodes in different orders, some nodes will store the first member's file, while others will store the other one. Fixing this situation after the fact is complicated, so we need to prevent it. Sending files to the nodes always in the same order would not work when somes nodes are temporarily disconnected or have very slow connections. We need to ensure members **always use different names for different files**. One way to generate a **unique name** is to produce a random sequence of characters. If the sequence is long enough, two members will never generate the same name, unless one does it on purpose. However, we also need to make sure **the data sent by a node is the original file**, exactly as intended by its author. We want to be able to detect any node's attempt to send invalid data. Crypgography provides a solution: **Identify the file using the *hash* of its content**, instead of a name. A hash has the property that in practice, two different files will always have a different hashes, and after downloading a file, you can compute the hash of its content, then verify that it matches the one you requested. ### Cryptographic hashes Blockchains make heavy use of cryptography to ensure a high level of security. One cryptographic primitive often used in a blockchain, including as a key component of the chain structure itself, is *cryptographic hashing*.  A **hash** is a sequence of bytes that is the output of a **hash function**, where the input is an arbitrarily large piece of data. There are many types of hash functions with different properties, but most share these three main ones: - the size of the hash is limited, typically from a few bytes to a couple of hundred bytes - changing a single bit of the input significantly changes the output, which makes it look random - given the same input (and sometimes for a given value of an internal seed), hash functions always produce the same hash (determinism) In blockchains, we use **cryptographic hash functions**. Such hash functions have these additional properties: - collision resistance: it is unfeasible in practice, to find two different inputs that yield the same hash, - pre-image resistance: it is also unfeasible to find an input (pre-image) that ouptputs a given hash, with no better strategy than trying every possible input and computing its hash. With these properties, the hash of some data can be seen as a unique fingerprint that identifies this data. Tezos uses _BLAKE2b_, a cryptographic hash function that takes any sequence of bytes as input and produces 32 bytes (256 bits) hashes. Another well known example is _SHA256_. As an example, fig. 1 shows the hash of the small string "Cake", expressed using 64 hexadecimal digits. Fig. 2 shows the hash of a longer string. Note that the two hashes are completely different, but both are 64 digits long. ![](small_hash.svg) FIGURE 1: The hash of a small string of characters ![](big_hash.svg) FIGURE 2: The hash of a large string <NotificationBar> You have probably already used hashes without knowing it. Indeed, when you download a file on your computer, some browsers check the hash of the downloaded file and compare it to the hash announced by the source before download. If the two hashes match, it means that the file you have downloaded is a perfect match to the one intended to be sent by the source. If the hashes don't match, your download has been corrupted. You can try this out manually by downloading the latest release of _Ubuntu_, computing the hash of the downloaded file, and comparing it to the one announced on [their website](https://ubuntu.com/tutorials/how-to-verify-ubuntu#5-verify-the-sha256-checksum). </NotificationBar> ### Reducing bandwidth needs With a centralized approach, a member only has to upload new content once to the central entity, therefore minimizing bandwidth needs. With our basic decentralized approach, as the community grows and the number of nodes increases, it becomes prohibitive for the author of new content to send their data to every single node in the network. Limiting the number of nodes would limit the bandwidth for uploading, but increase the amount of bandwidth required for nodes to reply to download requests. **How can we solve this dilemma?** Assuming we still want every node to store all of the data, the total bandwidth used by the community can't be reduced. What we can reduce however, is the bandwidth needed for a single user or node. This means: - **when uploading**, a member should only send its data to a subset of the nodes. - **when downloading**, members shouldn't all send their requests to the same node. If a user only sends their data to a subset of the nodes, this means these nodes must in turn send their data to the remaining nodes. For this, we organize the nodes as a **peer-to-peer network**, where each node knows a subset of other nodes, called its **neighbors**. When a node receives a file it doesn't already have, it asks each of its neighbors if they already have that file (using the hash of its content as an identifier), and sends it to the ones that don't. As long as the network is strongly connected, i.e. not split in two parts where no node of one part knows a node of the other part, then the file will quickly propagate through the entire network. Every node will then store a copy of the file. To ensure the network is connected, we make sure each node knows a large enough subset of the other nodes that is picked at random. The peer-to-peer network can be called *p2p* for short. In the context of blockchains, we also call it the **gossip network**. When downloading data, different members can simply connect to different nodes, to **spread the load**. If a node is missing the requested file, for example because it was disconnected during its propagation, it can use the p2p network to obtain it from another node, by sending the same request to one of its neighbors. Check [this chapter](TODO) to learn more about the p2p network. ### Avoiding DOS attacks Our basic p2p network is vulnerable to **Denial Of Service** attacks (DOS for short), where a malicious member sends so much data to the network, or so many requests, that it saturates the network and makes it unavailable for other members. One common approach is to limit the amount of data or requests that a given member, or a given IP address, can perform, then reject any requests beyond these limits. However, if we keep the community open, an attacker can easily use a large number of machines with different IP addresses, or impersonate a large number of members, to go around such limits. Furthermore, strict limits may prevent legitimate intensive uses of the network. Can you think of another solution? One approach that works well consists in **making attacks costly** for anyone trying to attack the network. There are mutiple ways to make it costly: - require users to **perform a significant amount of computing for any request**. This implies spending computing resources and electricity. This approach called *Proof of Work* (PoW for short), has the unfortunate side effect that it wastes energy and is therefore bad for the environment. Its use should therefore be limited. We talk about PoW in more detail later (TODO Link). - require users to **pay for every operation**. The payment could be transferred to the nodes that do the work, which means this approach would double as an incentive for members to contribute their own nodes. This implies handling transfers of amounts of currency, which is one of the reasons why cryptocurrency is usually involved with decentralized architecture. ## Decentralized currency ### Accounts and transfers For our community to be able to manage its own currency, we need to support at least a few basic features. We need each member to have: - A unique account identifier, or **address**. - Some amount of currency it possesses, the **balance** of the account To use it, a member needs, to be able to, at the minimum: - Transfer some currency from their account to another member's account. - Receive currency from another member. On Tezos, the native currency is called **Tez**. How would you implement this for our community? ### Centralized approach We could use a centralized approach by appointing one of the members of the community as a banker. The banker would keep a **ledger** of all transactions it processes. They would also keep track of the current balance of each account. Whenever a member requests a transfer: - the banker checks their identity - they check that the balance is sufficient - they reduce the balance of the source, and increase the one from the destination - they charge for this service However, such a banker, may, similarly to a hosting company: - be unavailable, or go bankrupt - block some transfers - create fake transfers, or other illegal use of the funds Again, using such a centralized approach means users have to trust a single entity, that has full control over the funds. This can be very dangerous. ### Decentralized approach Think about how our community could maintain the balances of accounts and handle transfers, without having to trust a single entity. We could build on top of our p2p data sharing network, and have each node contribute equally to supporting this currency. A node would have to be able to: - **Receive** and **emit** transactions - **Keep track** of the **balance** of each account - **Check the validity** of these transactions - Authenticate their author - Check that the balance is sufficient How can we do this? **Receiving and emitting transactions** could be handled the same way as receiving and emitting files in our p2p network. When a nodes receives a transaction: - It performs some verifications (to avoid DOS attacks) - It propagates it to its neighbors **Maintaining the balance of each address** could be done by each node based on the transactions it receives. For each member's **address** (unique identifier), each node can store a corresponding **balance**. Once a transaction is validated and confirmed, the node will need to: - **Subtract** the transferred amount from the balance of the source address - **Add** this amount to the balance of the destination address ### Authentication To validate a transaction, the node first needs to **authenticate its source**. For example, let's take the following transaction: Alice transfers 50 tez to Bob Before the node substracts 50 tez from Alice's account and adds 50 tez to Bob account, it has to check that Alice is the author of this transaction. This can be done using **asymmetric cryptography**. Each member generates and stores: - A **private key**, that they are the only one to possess, and allows them to produce a digital signature for a certain piece of data: “I, Alice, certify that for my transaction #284, I transfer 50 tez to Bob” - A **public key**, that they share with the whole network, and allows: - For the user to uniquely identify themselves (their account) - For any member, to verify that they are the author of a signed message Tezos users use a Wallet (Kukai, Umami, Temple, Ledger, …) to generate and store their private keys and sign transactions. In practice, the address of an account is based on the hash of the public key of the holder of that account. ### Checking that the balance is sufficient At first, it may seem like all a node needs to do when receiving a transaction, after authenticating its author, is to check that the balance of the account of the source of the funds is more than the amount it transfers to the destination. In a decentralized network however, it is not that simple. Let's assume that we already found a way to make sure every node in the p2p network receives every transaction. A key remaining issue is that the validity of transactions may depend on the order in which a given node receives them. Assume that at the start, Alice has 100 Tez and Bob has 10 Tez. We have 2 transactions: - Transaction A: **Alice transfers 50 Tez to Bob** - Transaction B: **Bob transfers 30 Tez to Carl** **If a node applies A first**, Bob’s balance becomes 60 tez. **B is valid** and can be executed. **If a node applies B first, B is invalid:** Bob’s balance is 10 Tez, which is too low for a transfer of 30 Tez. These two nodes end up in a different state! As all nodes should agree on the balance of each account, they not only need to agree on which transactions need to be performed, but also on their order. A key aspect of managing a currency on a decentralized network is therefore to agree on **which transactions to add, and in which order**. ## Deciding on transactions to include and their order ### Ordering transactions and associated issues Assuming again that each node receives every transaction sent to a node by their author, how would you make sure every node executes them in the same order? One natural idea would be to attach a precise timestamp to every transaction, then have nodes excute transactions in the corresponding order. Can you think of any issues with that approach? One issue is the case where two transactions have the same timestamp. This could however easily be resolved by sorting these transactions using their hash, which is unique. Another issue is that to execute a given transaction, you would need to make sure you already received every transaction with a smaller or equal timestamp. One could consider allowing for some set delay to account for network issues that could slow the propagation of some transactions. However, if nodes reject transactions that arrive too late compared to their attached timestamp, two nodes may reject different transactions and therefore end up in different incompatible states. Another approach could be for nodes to revert to a previous state, whenever a transaction arrives after the application of transactions with a higher timestamp, then reapply the transactions in the right order to get the new updated state. Assuming that all nodes eventually receive all transactions, they would always converge to the same state. This however means that anyone who had inquired about the state from such a node before a revert, would have obtained inaccurate information, and potentially made important decisions based on that information. ### Double spending example Let's say Carl wants to purchase items from both Daphne and Eve, for 20 Tez each, but only has 30 Tez on his account, Carl could send the following transactions to the network, with timestamps in this order: - Transaction A: **Carl transfers 20 Tez to Daphne** - Transaction B: **Carl transfers 20 Tez to Eve** Now let's say that the following steps happen in this order on a given node: - Transaction B is received. - Transaction B is executed. Carl and Eve's balances are updated. - Eve checks she received payment, and sends her item to Carl - Transaction A is received. - The node reverts to the initial state, resetting Carl and Eve's balances. - Transaction A is executed. Carl and Daphne's balances are updated. - Transaction B is executed but fails, as Carl doesn't have enough funds on his balance. - Daphne checks she received payment, and sends her item to Carl We can see that although Carl only had 30 Tez, he ended up receiving two 20 Tez items, with 10 Tez left on his account. This situation is a case of what we call **double spending**: using the same tez for two different transactions. Here, this is done by taking advantage of synchronization issues. A system where nodes eventually agree with eachother on which transactions are executed in which order and on the resulting state is not sufficient: we need a way to eventually reach **finality**: a situation where a node can guarantee that all the transactions executed up to a point are **final**, and that the community collectively agrees. Note that here, Carl could have purposely sent transaction A with a timestamp in the past, after sending transaction B and checking that Eve already sent the item. It could also have simply been due to some congestion issue. As Carl may be in control of some nodes, there is no way to differentiate between the two. ### Using blocks To summarize, we need a way for nodes to collectively agree on which transactions to include, and in which order, with points in time where given transactions become final. Another way to see it is that we need a mechanism for nodes to collectively agree once and for all on what the next transaction is, and keep doing this indefinetely. Whatever mechanism we put in place, however, will require nodes to communicate with eachother and exchange many messages over the network. Doing all this for every transaction, no matter what the exact mechanism is, would be prohibitively slow and consume a lot of bandwidth. Assuming we do have a very good mechanism for nodes to agree on the next transaction, how could we significantly reduce the number of messages ? The solution is to avoid applying this mechanism for every transaction, and instead, group transactions and apply it for every group of transactions. Instead of agreeing on the next transaction, nodes agree in one application of the mechanism, on the next X transactions and their order. On a blockchain, we call such a group of transactions a **block**. A block is mostly a sequence of transactions (and other kinds of operations), to be applied by every node, in order. ### Blockchain structure To summarize what we have seen so far: - A blockchain is a set of nodes that receive transactions from users, propagate them through a peer-to-peer network, and collectively select them and include them in a sequence of transactions (and other operations). - For performance reasons, this sequence of transactions is split in groups called blocks, and some mechanism is applied for the nodes to collectively agree on what the next block is, therefore forming a chain of blocks, hence the name **blockchain**. - Each node applies every transaction of the chain in the order of the sequence, using the same software, to maintain an internal state. Typically, this state includes the balances of all users' accounts. As all nodes apply the same transactions in the same order, they all end up with the same state. - Transactions are discarded if they are invalid, either because they are not correctly signed by their author, or when their application is invalid, for example due to lack of funds in the balance of the source account of a transfer. On top of the sequence of transactions (and other operations), each block contains a header with a small amount of extra information such as a timestamp, the position of the block in the chain (the level), and more, but most importantly, the hash of the content of the previous block. This hash uniquely identifies the previous block, making it a link to this block, forming a chained structure. As part of the mechanism for nodes to agree on what the next block in the chain should be, multiple blocks may be created and propagated, that link to the same previous block. As there can be only one next block in the chain, the goal of the mechanism is to make sure there is consensus on which block should be the official (final) next block.  ## Consensus mechanism We need some way for a next block to be proposed, based on some set of transactions, and some may for the community to agree that one such block is indeed the official, final (definitive) next block in the chain. The mechanism used for this is called the **consensus mechanism**. ### Centralized production of blocks As the goal of grouping transactions in blocks is to avoid exchanging messages for every transaction, proposing a next block is not something that can reasonably be done collectively. One of the nodes has to take this responsibility, select a set of transactions among the ones it has received since the last block, define an order for these transactions, and group them in a block. This block can then be propagated through the p2p network, and the process of having the community agree that this should be the next block, can then take place. On Tezos, we call the entity that creates a block a baker. On other blockchains, it can be called a miner, or validator. As one entity, a baker, gets to create block, this implies some centralization, with the issues that come with it. In particular, the baker may: - censor some transactions - give priority to other transactions - entirely fail to do its job and not create any block For the first two points, it may be for a number of reasons, such as favoring entities it likes, or simply censor or give priority to transactions depending on whether it benefits from it. To avoid the issues that come with this centralization and the power a baker has, the solution is to distribute this power and responsibility over time: **for each new block, we select a new baker**. ### The difficulty of selecting a baker For each block, a baker has to be somehow selected, so that the responsibility of creating the next block is not concentrated on one entity, or on a small number of entities. Think about what algorithm you would you use to select a baker for each block, so that this power/responsibility is spread fairly among the community, thus ensuirng decentralization? A natural answer would be to randomly select among all the different available bakers, and spread the responsibility evenly. Unfortunatly, this doesn't solve the problem. Can you find out why? The issue is that as a blockchain is public and permissionless, we need anyone to be able to become a baker, and participate in ensuring the security of the blockchain. But if anyone can be a baker, this also means anyone can be multiple bakers. If there are N bakers, then one entity registers as N new bakers, then if we select the next baker randomly among available bakers, this single entity would have one of its bakers selected for half of the blocks on average, and gain too much power. Making sure every baker is a unique entity, and that several such entities are not in practice controlled by the same entity, can't be done without a centralized authority in charge of investigating and controlling who can be a baker. This means we can't use a solution that depends on finding out who is behind each baker. The solution needs to be based on something that entities can't freely create an infinite amount of: some kind of resource. ### Proof of Stake One common resource an entity can't create an infinite amount of is money. On a blockchain, we can conveniently use the native cryptocurrency, as a way to represent this limited resource. It can be converted from and into other currencies through exchanges. This gives us way to select the baker for the next block: instead of selecting them randomly and evenly among all registered bakers, we can select them randomly, but in proportion to the amount of native cryptocurrency they posess. As owning a high proportion of the available Tez would be prohibitively expensive, it is unlikely that a single entity would take too much control this way. Approaches based on how much cryptocurrency an entity has, as a way to distribute the responsibility of creating the next block is called *Proof of Stake*. This is the approach used by most modern blockchains. Tezos was one of the first blockchains to use Proof of Stake as the way to assign block creation. Since then, many blockchains adopted this approach.  ### Proof of Work Another approach that was selected initially by some blockchains, including the first blockchain, Bitcoin, is to use computing power as the limited resource used to select who gets to create the next block. The idea is that to have a chance at being the one to produce the next block, you have to perform a large amount of computation. The more computation you can perform in a given amount of time, the more likely you are to produce the next block. For similar reasons to money, having a high proportion of the computing power dedicated to a blockchain can be very hard and costly to achieve, so this can be effective as a way to distribute the ability to create blocks among many entities. An example of computation that is being used by some blockchains for PoW, consists in, given some data such as the content of the block being produced, to find a value for some extra piece of data to be included, such that the hash of the resulting data has a certain property. For example, the goal can be to obtain a hash that has its last N bits set to 0. As there is no way to control the output of a cryptographic hash function, other than trying different inputs and computing the output for each of them, the value of N directly impacts the average number of hashes that need to be computed, in order to get the required property. Proof of Work has a very significant drawback: to prove that an entity has significant computing power, this computing power has to be spent, and it is typically spend in a way that has no other benefits. This causes waste of huge amounts of computing power and electricity, with corresponding effects on the environment. A [study](https://www.jbs.cam.ac.uk/2022/a-deep-dive-into-bitcoins-environmental-impact/) from the university of Cambridge estimated that in 2022, the largest PoW cryptocurrency, produced about 0.3% of global annual greenhouse gas emissions. This is the main reason why modern blockchains tend to abandon PoW in favour of PoS as a way to distribute the block creation power. Note that some very minor of PoW can be used in PoS blockchains, as a way to prevent DOS attacks. ### Incentives As being a baker (or miner) means taking the time to setup and administer one or more servers, and in the case of PoW blockchains, spending significant amount of electricity, there needs to be some incentive to encourage as many people as possible to take (and share) this responsibility. Being a baker for a given block can give some amount of power. However, as everything is done to limit this amount of power, and taking advantage of this power is not easy, some other, more direct incentive is needed. A system of rewards is therefore put in place: whoever creates the next block, will be rewarded in the native cryptocurrency of the blockchain. This reward can be composed of: - some amount of newly minted cryptocurrency - fees paid by the emitter of transactions TODO: rewards incentivize bakers to behave well: - failing to produce blocks when it's your turn  ### Slashing As being in charge of creating the next block is a responsibility, bad behavior has to be deterred: - producing multiple blocks in a single round - attesting or pre-attesting multiple blocks in a single round When using Proof of Stake, instead of simply considering how much bakers own, we let them put some amount of cryptocurrency at stake, temporarily locked, so that if they are proven to badly behave, some of these funds will be taken from them as a punishement. This is what we call slashing  ### Delegation  To increase decentralization, and as not everyone has enough funds that they can lock in their account, or the ability to setup a server and bake, we need a way for more people to participate in securing the blockchain without these risks and responsibilitues. On Tezos, a system of delegation is available to fulfil this purpose: anyone who owns some tez can **delegate** their tez to the baker of their choice. The delegated tez are added to the stake of the baker, and contribute to increasing their chance of being selected for the next block. As delegated tez are not locked and not at risk of being slashed, only a limited portion  of the tez for a given baker can come from delegation. In exchange for the tez delegated to them, bakers in turn, share a portion of their rewards among delegators. Each baker chooses the rules on how much and how they do so, creating a competitive market between bakers. ## Smart Contracts Once we have a system for a P2P network of nodes to agree on a sequence of transactions to execute in a specific order, we can apply this system to all kinds of transactions. ### Virtual machine If we push this to the extreme, we could imagine expanding transactions to anything a computer could possibly do, in other words, any piece of code. This would require for nodes to agree on a format to represent code (some programming language), and on an API, a defined set of functions that code can use to interact with its environment. Of course, the type of code that any user may send in a transaction to be executed on every node has to be limited. Try to think of what limitations would be required, before you continue. Here are the main limitations required for this to work: - a given transaction needs to have the **exact same effect** on every node, as their state need to be identical after each block, no matter where or when the execution happens. - the **execution time** of a transaction needs to be limited, so that the whole network doesn't become slow - the effect of a transaction sent by a given user has to be **restricted to what other users agree** they are allowed to do This means all the code that will be run needs to be executed in some type of sandboxed **virtual machine**: a well defined, limited environment, with no access to the outside world. Indeed, the "outside world", whether it's some external service or content on the machine or online, may be different from node to node, so accessing it could produce different results depending on the node or on when the execution takes place. What's left is code that interact with the data stored in the node itself. This can include not only the balances of accounts, but other types of data such as information about NFTs and their owners, scores of games, references to pieces of art, etc. ### Smart contracts and calls For users to agree on what can be done without limiting use cases, the execution of code is divided in two steps: - Storing pieces of code that are made publically available. These are what we call **Smart Contracts**. They store their own dedicated data that can only be modifierd by them. The code of a contract may only modify this data, or emit its own new transactions (transferring tez or calling other smart contracts). - Calling these smart contracts with given parameters, wich executes the code. These are two new types of transactions on Tezos: **contract originations** (we also talk about deployment), and **contract calls**. With this approach, someone can create a set of rules in the form of a smart contract, as to how its data is modified depending on who calls them with what parameters, then potential users can check the code of the contract and make sure they agree with its behaviour, before they call them. A smart contract may have multiple entrypoits, like the functions or methods of the contract, each with their own parameters and code. When we call an entrypoint, we can pass our own parameters. Other information, such as who is making the transaction, how many tez they sent to the contract along with the call, or what the current date is, can be accessed to the code, along with the contract's own storage. ### Smart contract example Here is a very basic example of smart contract: Storage: - owner: an address (of the current owner) - price: a number of tez Entrypoints: - purchase() - check that the amount sent by the caller equals the price - send this amount to the current owner - change the owner to the address of the caller - setPrice(newPrice) - check that the caller is the owner - set the price to newPrice This contract in itself is a digital property that people can purchase or sell. A contract like this could also be used to authenticate the ownership of an associated physical item. Once deployed, this contract can never be changed. This means that when a user calls the purchase entrypoint and send money, they can be certain that if the execution takes place, they will become the new owner of the contract, and be able to then set the price at which they are willing to sell it later. Only the owner can change the price, and noone can ever prevent them from selling the ownership to whoever wants to purchase it. Smart contracts open blockchains to all kinds of use cases, decentralized finance, art, gaming, decentralized identity and more. ### Smart contract flaws Talk about the risk of bugs ## Governance - upgrades Already in other section. Do we still mention it?

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.