Mastering Web3 with Waves Module #3

Published in

Mastering Web3 with Waves

9 min readJul 7, 2019

Module #3 Introduction to Smart Contracts and Smart Accounts

It’s “Mastering Web3 with Waves” online course. Module 3.
In this module, we’ll talk about smart contracts, how they work and how to use them to implement our Web3 decentralized application — Coupon Bazaar.

3.1 Overview;
3.2 Introduction to Smart Contracts;
3.3 Smart Contracts in Waves and Smart Accounts;
3.4 Security issues and Multi-signature Smart Accounts;
3.5 Smart Accounts and Decentralised Applications (dApps);
3.6 Practice: “Coupon Bazaar”

Let’s go!

Traditional contracts represent agreements between participants (parties), these agreements are validated and enforced by some third-party official entity or government. Third-party entities are key participants for validation of contract’s conditions, environmental circumstances, and events which could influence the contact’s agreement execution.

Despite similar terms, smart contracts aren’t contracts by definition of “agreement between parties”. The smart contract is a computer source code or program which can be executed within a distributed environment like blockchain network. All operations and execution results are stored in a blockchain.

In this definition, the smart contract is not a contract between parties, but it’s a protocol of cooperation between users, and also between user and computer or even computer and computer according to rules described in the smart contract source code.

The smart contract is program code for the computer. It is a set of instructions which include different checks and validations, read and write data operations, operations with digital assets (like transfers, issuing, burning, freezing, etc). Remember that the main technology for Web3 is blockchain, or more general DLT (distributed ledger technology).

Smart Contract is executing on hundreds of machines simultaneously.

Because of that Smart Contracts have several nice features:

- No middleman

- Secure storage for digital assets

- Code is a law

- Backups by default

- Avoid manual error

- Trustless execution

- Autonomous execution

Some of you might be heard about Ricardian contracts — an innovation from the 90s.

It’s a digital form of tradition contracts. The Ricardian contract has two parts: human readable terms and machine-readable components. Digital signatures and operations automatization is used here. But despite of digital nature Ricardian contracts aren’t smart contracts they are still traditional contracts. They have the legal power, but smart contracts don’t.

Ricardian Smart Contracts are the best combination.

Different DLT platforms have different approaches to smart contracts realization.

Waves Smart Contracts are represented by two different types: Smart Accounts and Smart Assets. We’ll practice with smart assets later in this course.

Any Waves account can be converted to the smart account by applying special account-script. Account script is a program code on RIDE language which contains a set of conditions for allowing and deny different types of outgoing transactions.

Technically creation and deploy of waves smart contract have several stages:

RIDE code, compilation, generating of set script transaction, validation by one node, UTX pool between all nodes and then inserting transaction with the script to the new block.

In a more accurate overview there are actually more steps:

- Waves IDE validates RIDE code

- RIDE code is compiling to the sequence of base64-format symbols

- set script transaction is used to send compiled code to the blockchain node

- Deserialisation and syntax check, names and variables, functions invitations

- Cost calculation, types and signatures checks

- After checks and validation from the first node, the set script transaction is going to inter-nodes UTX pool

- All other nodes are making deserialization and cost computation steps

- Miner-node are making deserialization and cost computation steps before new block validation and insertion into the blockchain

- After receiving the new block all nodes are making deserialization and cost computation steps

Now the script is executing on all nodes and participating invalidation of all outgoing transactions from the smart account

The smart script allows or denies some outgoing transactions depending on certain conditions. This logic depends on several data sources: account data, transaction data, blockchain state, and data.

What is the difference between the default account and smart account?

Default account has only one signer, who can use his private key and seed to sign all outgoing transactions. Any other user can’t use his digital signature to sign transactions from default accounts that don’t belong to this user.
Bob can’t sign a transaction from Alice’s account and vice versa.

But Alice can set the script on her own account by making a smart account from default account. To do that Alice should sign the set script transaction first.

When default account becomes a smart account, anyone is able to sign some certain outgoing transactions depending on smart script logic.

Let’s talk about security issues!

Account script must check conditions and allow types of outgoing transactions and users who can sign those transactions. This is a very critical moment! It’s the most popular place for security vulnerabilities.

Remember: We’re building a decentralized Web3 coupon marketplace — “Coupon Bazaar”.

Users are searching for goods and services discounts and they can buy them for a small price in the marketplace.

Each coupon — is a digital asset which represents a special discount from the supplier.

“Coupon Bazaar” is a marketplace. It provides matching, payments operations and delivery service between suppliers and customers.

Functionality for Suppliers:

A supplier registration
Items management
Purchases confirmation

Functionality for Customers:

Find coupon
Purchase coupon

Suppliers:

• Registration
• Add/Remove/Update Items
• Purchases confirmation

2. Customers:

Search
Purchase

To work with decentralized data storage by using data transactions we allow data transactions for suppliers and deny all other transactions except set script transaction. Set script transaction is required for us to update the smart account logic in the future. Please, pay attention to the vulnerability: Now, any user is able to sign the outgoing transaction.

Anyone is able to change the account script on this account and withdraw all funds after that.

In order to allow change script only for dApp owner, we should use the sigVerify function. Using this function we can check that signature, from an array of signatures called proofs, belongs to dApp owner.

We can use the sigVerify function in matcher within verify() function. sigVerify returns a TRUE boolean value when dApp ones sign the transaction and FALSE otherwise.

Let’s look at the classical example of smart accounts usage to increase security for digital assets storage — multi-signature accounts (multi-sig).

For instance, our suppliers are small businesses consisting of several founders or administrators (three in our case). To withdraw funds from the multisig account at least two from three signatures are required for the outgoing transfer transaction.

This multisig account also protects the online store from hacks when one owner’s private key or seed is been compromised or stolen.

To implement multi-signature account with at least two signatures we should declare public keys of valid account signers. Participants are able to sign the transaction in a different order, so we should check all combinations then.

To sign one transaction several times we should pass the transaction javascript object several times to the same function. For instance transfer function in our case.

Let’s talk about decentralized applications!

In our Web3 application supplier should confirm purchases. Let’s see how to automatize that.

1. Suppliers:

• Registration
• Add/Remove/Update Items
• Purchases confirmation

2. Customers:

Search
Purchase

Using smart contracts were able to build decentralized web3 applications.

“Decentralized applications (dApps) are applications that run on a P2P network of computers rather than a single computer. dApps, have existed since the advent of P2P networks. They are a type of software program designed to exist on the Internet in a way that is not controlled by any single entity. Decentralized applications don’t necessarily need to run on top of a blockchain network. BitTorrent, Popcorn Time, BitMessage, Tor, are all traditional dApps that run on a P2P network, but not on a Blockchain (which is a specific kind of P2P network).”

But in our definition: dApps is a ‘blockchain enabled’ websites, where the Smart Contract is what allows it to connect to the blockchain. The easiest way to understand this is to understand how traditional websites operate like our “Coupon Bazaar” dApp integrated with Waves blockchain and waves keeper browser extension.

In order to make a dApp development process easier for developers, RIDE- Waves smart contract language has two types of functions:

@Verifier and @Callable.

We are already familiar with @Verifier.

@Callable functions are able to be called by users from outside. As a result of the execution, new information can be inserted or updated in dApp key-value data storage or (and) funds can be transferred from dApp balance to the caller or other addresses depending on dApp logic.

In our case, dApp and smart account are the same entity.

Users are able to call @Calable functions and this process is called invocation. Appropriate generated transaction is invokeTransaction. We can use some information about invokeTransaction parameters inside smart contract script, for example, payment information: amount and payment currency (token).

In Coupon Bazaar we gonna use purchase function for purchases from customers and coupon purchase confirmation from the supplier.

Price for the item should be stored in dApp key-value storage (key: item_A_coupon_price).

We can extract the price using getInteger() function.

Customer should pay the exact amount to buy coupon otherwise smart contract generates exception with error description.

As you can see, the purchase will be automatically confirmed after the execution of the purchase function.

All records are stored in dApp key-value storage. This data was written by WriteSet function. The smart contract can read and rewrite this data during execution.

To call the @Callable function — purchase() we should use a new type of transaction and its wrapper in JavaScript — invokeScript().

We can use any key-value parameters in args array and payment details. To specify which function will be executed we should use the name of the @Callable function and specify a dApp account public address (or alias).