DEV Community: Owanate Amachree

Try it yourself! - Dogfood Your Web3 Ecosystem

Owanate Amachree — Fri, 29 Jul 2022 09:05:08 +0000

If you would like to follow along by doing the activities from the
RSK+RIF Activities Day
on your own, this is the post for you!

Note that this post is a list of the activity cards;
The solutions and spoilers have been saved for a subsequent post!

The original design of the activities ☝️

The physical cards for the activities used on the day ☝️

The rules are that these have to be completed sequentially -
complete each objective before moving on to the next one.
Consider doing this in a group rather than individually.
However, if that is not an option, some activities may not 100% work,
and you'll need to adapt accordingly (suggestions have been provided inline).

You might notice that some cards contain an Easter Egg.
These are for doing something more than just the base requirement of the activity.
As the name implies, these are not specified in the activity cards; finding them involves some guess work (and luck).
All team members need to complete the basic steps to move on to the next activity,
but only one team member needs to - optionally - complete the Easter Egg
to get the additional points.

OBJECTIVE #1

You have 30min to set up a new Metamask Wallet in a new Browser Profile of your computer and connect to RSK Mainnet.

Existing/current wallet not allowed. Save your seed phrase!!!

Then sign into the link below and connect to RSK Mainnet + add RIF token - metamask-landing.rifos.org

Every member of the team must submit the address at: forms.gle/XXXXX

Reward: 10 points

This objective is simply the set up for the rest of the sequence,
so that everyone starts on a level playing field with a fresh wallet.

Adaptations:

Use a spreadsheet or other shared doc instead of the google form.

OBJECTIVE #2

You have 5min to select your team name!

Write and show your name to the public.

Be creative

Reward: 10 points

This objective is simply to populate the leaderboard with names instead of team numbers.

Adaptations:

This task is simply to enable teams to appear on the leaderboard
Skip if not competing with multiple teams

OBJECTIVE #3

Two members of your group will receive RBTC from IOV.

Transfer among yourselves such that everyone has equal amounts.

You can check account balance at explorer.rsk.co

You have 25min for this task!

Reward: 20 points
Easter Egg: 20 points

This objective is to ensure that everyone has sufficient funds to perform the tasks in the rest of the sequence.
The amount needed is approximately 10USD worth of RBTC.

Adaptations:

Transfer in RBTC that you hold in another account; or
Obtain RBTC from an exchange
If doing this individually, skip the distribute equally step, instead just transfer to another one of your own accounts

OBJECTIVE #4

You have 30min to convert your 50% funds from RBTC to RIF Tokens.

You must use app.rskswap.com/swap or
live.sovryn.app/swap.

Reward: 30 points

This objective is to convert some cryptocurrency into utility tokens,
which will be used in some of the subsequent tasks.

OBJECTIVE #5

You have 40min to register a new RNS Domain (e.g. yourname.rsk)

Your domain must last for 2 years.

You must use manager.rns.rifos.org.

Reward: 40 points
Easter Egg: 20 points

This objective is to use some utility tokens,
to register a decentralised domain name.

OBJECTIVE #6

You have 20min to lend approximately 2USD worth of RBTC on Tropykus using the “microsaving” feature.

You must use tropykus.com.

Reward: 60 points

This objective is to use cryptocurrency as savings to earn interest.

Partners on stage, talking about their products, as they are being used during the activities day.

OBJECTIVE #7

You have 30min to mint RDOC on Money On Chain.

You must use rif.moneyonchain.com.

Reward: 60 points
Easter Egg: 20 points

This objective is to convert utility tokens into a stablecoin,
which will be used in some of the subsequent tasks.

OBJECTIVE #8

You have 45min to purchase a limited edition “IOV Gorra Digital Edition” from Kripton Market.

You must use marketplace.kriptonmarket.com.

Reward: 60 points

This objective is to use a stablecoin to purchase a retail item.

Adaptations:

These items may no longer be available, purchase any other item with approximately the same value instead.

Mini-spoiler: The "digital edition" was a bit of a troll 😉,
this activity was really about the purchase of a physical cap;
and was revealed right at the end of the activities.

OBJECTIVE #9

You have 10min to uninstall your Metamask wallet from your new Browser Profile.

Reward: 10 points

This task is to simulate "losing" your wallet.

OBJECTIVE #10

You have 35min to recover your wallet but now using Defiant (mobile) or Liquality (browser).

Ensure that your addresses/balances are intact. Hint: Check your derivation path.

Reward: 100 points

This task is to recover funds after "losing" your wallet.

So those are all the activities! If you do indeed try them out, be sure to drop your feedback and questions over at rsk.co/slack

Originally posted on Bguiz Blog.

More coming soon; this is the second in a series of posts!

Dogfood Your Web3 Ecosystem - The thinking behind it, and preparation for it
This post Try it yourself! - A list of all activities, (almost) no spoilers
Coming soon Demos - How the activities were completed and evaluated, spoilers aplenty
Takeaways - What we learnt from the entire process

RBTC vs. WRBTC: What are Wrapped Cryptocurrencies?

Owanate Amachree — Sat, 09 Apr 2022 09:56:22 +0000

Originally published on Hackernoon.

What is a Wrapped Token?

Wrapped cryptocurrencies or tokens are pegged to the value of another original crypto or assets like gold, stocks, shares, and real estate and put to work on the DeFi platforms.

They are a special type of ERC20 tokens, which typically prefix their token symbol with "W". For example, RBTC is the native cryptocurrency on the RSK Blockchain and WRBTC is an ERC20 token that wraps RBTC. This not only enables the RBTC denominated DeFi activity on DeFi platforms (which standardises on the ERC20 standard) but also consequently enables it to be used on other blockchain networks.

The original asset is 'wrapped' into a digital vault, and a newly minted token is created to transact on other platforms. Wrapped tokens allow non-native assets to be used on any blockchain, build bridges between networks, and implement interoperability in the cryptocurrency space.

How do they work?

The creator of the token; upon deployment usually creates the initial supply of the tokens (total number of tokens). This is known as a "mint" operation. In many ERC20 tokens that's all, but for some ERC20 tokens, the total supply needs to be increased or decreased after the initial deployment.

So the smart contract exposes a mint function, for increasing the total supply; and a burn function for decreasing the total supply. Of course, they don't simply allow that to happen for no reason, usually, a set of requirements must be met to use these functions,
and these smart contract functions check for that.

In wrapped tokens, the wrap operation performs a mint. The holder transfers cryptocurrency to the smart contract, the smart contract mints the equivalent amount of tokens, and finally, the smart contract transfers the tokens to the holder.

The unwrap operation does the reverse and performs a burn. The holder transfers tokens to the smart contract, the smart contract burns the equivalent amount of tokens, and finally, the smart contract transfers the cryptocurrency to the holder.

Difference between a wrapped vs an unwrapped token

Difference between BTC, RBTC, WRBTC, and WBTC

BTC is the native currency of the Bitcoin network.

RBTC is the native cryptocurrency of the RSK network. RBTC it is pegged 1 : 1 with BTC (1 RBTC = 1 BTC).

WRBTC is an ERC20 token that wraps RBTC. Both are on the same network, RSK. This is accomplished using a smart contract. See WRBTC on the RSK block explorer.

WBTC is an ERC20 token on the Ethereum network that is treated like wrapped BTC. However is not accomplished using smart contracts, and instead requires trust in an intermediary.

All four of these assets have equivalent value, they simply exist in different formats and on different blockchain networks.

Why use WRBTC?

Trade Directly with other Tokens
The reason you need WRBTC is to be able to trade RBTC for other ERC-20 tokens on decentralized platforms. Because decentralized platforms running on Rootstock use smart contracts to facilitate trades directly between users, every user needs to have the same standardized format for every token they trade. This ensures tokens don't get lost in translation.

No wrapping is done
When you "wrap" RBTC, you are trading via a smart contract for a token of equal value called WRBTC. If you want to get native RBTC back you need to "unwrap" it, via the same smart contract.

Source: Think and Dev

Other Benefits of using wrapped tokens?

Faster
The Rootstock blockchain processes transactions faster than the Bitcoin network. With RBTC and WRBTC, it's possible to use your BTC reserves on the Rootstock platform, conducting transactions faster.
Watch how to get RBTC using Sovryn and Liquality.

Promotes Interoperability
One reason for this is that ERC20 tokens all have a standard interface. The method to transfer ERC20 tokens is the same for any tokens that follow that standard. Every blockchain is different and enforces its own standards, meaning many tokens cannot be used across other chains. Wrapped tokens allow for non-native tokens to be used on other blockchains.

Increased Liquidity
There is only one cryptocurrency per blockchain network. Rootstock only has RBTC, and Ethereum only has Ether.

However, DeFi protocols want to be able to trade and perform other operations using multiple tokens, not just one. Combine that with token bridges that enable tokens to cross from one blockchain network to another. Combine all of this together and you get the ability to have Wrapped RBTC, Wrapped Ether, RDOC, and rUSDT all available on a single DeFi platform, which is pretty amazing!
Wrapped tokens increase liquidity and capital efficiency for exchanges, as they offer their users greater trading options.

Where to Get Wrapped RBTC (WRBTC)?

RBTC and WRBTC

To acquire wrapped RBTC, you can wrap your own RBTC by finding a WRBTC merchant such as RSKSwap. The merchant sends your BTC to a smart contract that mints the WRBTC-wrapped token at a 1:1 ratio and stores your deposited BTC. When you want to redeem your WRBTC for bitcoin, the merchant will send a burn request to the custodian who will then destroy the WRBTC and return your RBTC back to you.
For the more technically savvy, you can even perform the exact operations described above by interacting directly with the WRBTC smart contract.

BTC and RBTC

If you have BTC on the Bitcoin network, you may wish to convert it to RBTC on the Rootstock network. Watch this explainer video below or read about the RBTC Conversion on Rootstock Developers Portal.

For converting RBTC to BTC and vice versa, you can check out the guide here: RBTC Conversion or watch this explainer video

How to set up a Hardhat project for RSK Testnet

Owanate Amachree — Tue, 25 Jan 2022 16:09:35 +0000

Welcome to the tutorial on how to set up a Hardhat project for RSK Testnet. In this tutorial, we'll do the following steps:

What is Hardhat?
Setting up your environment
Creating and configuring a new Hardhat project
Writing and compiling smart contracts

Prerequisites

To follow this tutorial, you should have knowledge in:

JavaScript
Command Line
Git
Smart contracts basics

If you are not familiar with the above, it will be advisable to learn the basics by clicking the links above, before proceeding with this tutorial on how to set up a hardhat project.

What is Hardhat?

Hardhat is a development environment that enables a developer to compile, deploy, test, and debug your RSK software. It helps to manage and automate the recurring tasks that are inherent to the process of building blockchain applications.

1. Setting up your node.js environment

Most Hardhat libraries and tools are written in JavaScript, and so is Ethereum libraries and tools. Node.js is a JavaScript runtime environment built on Chrome's V8 JavaScript engine. It's the most popular solution to run JavaScript outside of a web browser and Hardhat is built on top of it.

1.1. Installing Node.js

You can skip this section if you already have a working Node.js >= 12.0 installation. If not, here's how to install it on Ubuntu, MacOS and Windows.

Linux

sudo apt update
sudo apt install curl git
curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -
sudo apt install nodejs

Windows

[Git's installer for Windows](https://git-scm.com/download/win)
node-v12.XX.XX-x64.msi [from](https://nodejs.org/dist/latest-v12.x/) here

Mac OSX

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.35.2/install.sh | bash
nvm install 12
nvm use 12
nvm alias default 12
npm install npm --global # Upgrade npm to the latest version

2. Creating and configuring a new Hardhat project

Lets install Hardhat using the npm CLI. The Node.js package manager is the world's largest Software Registry that contains over 800,000 JavaScript code packages. Go here to learn more about npm

Open a new terminal and run the below command

mkdir hardhat-tutorial-guide
cd hardhat-tutorial-guide
npm init --yes
npm install --save-dev hardhat

In the same directory where you installed Hardhat run:

npx hardhat

Select Create an empty hardhat.config.js with your keyboard and hit enter, do the same for the remaining prompts

When Hardhat is run, it searches for the closest hardhat.config.js file starting from the current working directory. This file normally lives in the root of your project and an empty hardhat.config.js is enough for Hardhat to work. The entirety of your setup is contained in this file. Hardhat will create a hardhat.config.js like the following:

/**
 * @type import('hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: "0.7.3",
};

2.1. Configure `hardhat.config.js` to connect to RSK Testnet

To set up your config, you have to export an object from hardhat.config.js. This object can have entries like defaultNetwork, networks, solidity, paths and mocha.

2.2. Network configuration

The networks config field is an optional object where network names map to their configuration.

There are two kinds of networks in Hardhat: JSON-RPC based networks, which is what we will be using in this tutorial, and the built-in Hardhat Network.

You can customize which network is used by default when running Hardhat by setting the config's defaultNetwork field. If you omit this config, its default value is "hardhat"

2.3. Hardhat Network

Hardhat comes built-in with a special network called hardhat. When using this network, an instance of the Hardhat Network will be automatically created when you run a task, script or test your smart contracts.

Hardhat Network has first-class support of Solidity. It always knows which smart contracts are being run and exactly what they do and why they fail. Learn more about it here.

2.4. JSON-RPC based networks

These are networks that connect to an external node. Nodes can run on your computer, like Ganache, or remotely, like RSK Testnet. We'll be configuring a network connection named rsktestnet for this tutorial.

Include the following code in your hardhat.config.js file

/**
 * @type import('hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: '0.7.3',
  networks: {
    rsktestnet: {
      chainId: 31,
      url: 'https://public-node.testnet.rsk.co/',
      gasPrice: Math.floor(minimumGasPriceTestnet * TESTNET_GAS_MULT),
      gasMultiplier: TESTNET_GAS_MULT,
      accounts: {
        mnemonic: mnemonic,
        initialIndex: 0,
        path: "m/44'/60'/0'/0",
        count: 10,
      },
    },
  },
};

To set such networks, you’ll have to configure the object with the following fields:

url: This is the url of the node for custom networks.
chainId: This number is used to validate the network Hardhat connects to.
gasPrice: Its value should be auto or a number. Default value: auto
gasMultiplier: Default value : 1
accounts: This field controls the account that Hardhat uses. It can use node’s accounts or an HD Wallet. Default : “remote”.

2.5. HD Wallet Configuration

For using HD Wallet with Hardhat, you’ll have to set your network’s account with the below fields.

mnemonic: A string that is your seed phrase of the wallet
path: the HD parent of all derived keys. Default value : m/44'/60'/0'/0.
initialIndex: Initial index to derive. Default value : 0
count: Number of accounts to derive. Default value: 20

2.6. Solidity configuration

The solidity config is an optional field that can be one of the following:

A solc version to use, e.g. "0.7.3".
An object which describes the configuration for a single compiler. It contains the version, which is the solc version to use, and settings like optimizer with enabled and runs keys.

  solidity: {
    version: "0.7.3",
    settings: {
      optimizer: {
        enabled: true,
        runs: 200
      }
    }
  },

2.7. Path configuration

You can customize the different paths that Hardhat uses by providing an object to the paths field with the following keys:

root: The root of the Hardhat project. This path is resolved from hardhat.config.js's directory. Default value: the directory containing the config file.
sources: The directory where your contract are stored. This path is resolved from the project's root. Default value: './contracts'.
tests: The directory where your tests are located. This path is resolved from the project's root. Default value: './test'.
cache: The directory used by Hardhat to cache its internal stuff. This path is resolved from the project's root. Default value: './cache'.
artifacts: The directory where the compilation artifacts are stored. This path is resolved from the project's root. Default value: './artifacts'

Paths: {
    sources: "./contracts",
    tests: "./test",
    cache: "./cache",
    artifacts: "./artifacts"
},

2.8. Mocha configuration:

You can configure how tests are running using mocha entity, it would accept the same options as Mocha.

mocha: {
    timeout: 20000
}

Let's look at some other statements in the hardhat.config.js file.

const fs = require('fs');

require('@nomiclabs/hardhat-ethers');
require('@nomiclabs/hardhat-waffle');

const TESTNET_GAS_MULT = 1.1;

The first line const fs = require('fs'); provides access to the NodeJs built-in File System, fs module.

The second line, require('@nomiclabs/hardhat-ethers'); gives us access to the plugin that brings to Hardhat the Ethereum library ethers.js, which allows you to interact with the Ethereum blockchain in a simple way. This plugins adds an ethers object to the Hardhat Runtime Environment.

The third line, require('@nomiclabs/hardhat-waffle');
gives us access to the plugin for building smart contract tests using Waffle in Hardhat, this plugin adds a Hardhat-ready version of Waffle to the Hardhat Runtime Environment, and automatically initializes the Waffle Chai matchers. This object has all the Waffle functionality, already adapted to work with Hardhat.

The line const TESTNET_GAS_MULT = 1.1; declares a constant that stores the gasMultiplier value to be used in the network object.

const mnemonic = fs.readFileSync('.testnet.seed-phrase').toString().trim();
if (!mnemonic || mnemonic.split(' ').length !== 12) {
  console.log('unable to retrieve mnemonic from .secret');
}

The line const mnemonic = fs.readFileSync('.testnet.seed-phrase').toString().trim(); enables the Hardhat configuration file to read the mnemonics from a .testnet.seed-phrase file present in the Hardhat project directory. This is done using the following lines already present in the hardhat.config.js file.

The preceding script reads the .testnet.seed-phrase file from the filesystem and sets in the mnemonic variable. This variable can be used in the configuration to read the BIP39 mnemonic keyword.

If this file is not present, you should create this file under the Hardhat project and add your BIP39 mnemonic seed keywords in plain text.

const gasPriceTestnetRaw = fs
  .readFileSync('.minimum-gas-price-testnet.json')
  .toString()
  .trim();
const minimumGasPriceTestnet = parseInt(
  JSON.parse(gasPriceTestnetRaw).result.minimumGasPrice,
  16,
);
if (
  typeof minimumGasPriceTestnet !== 'number' ||
  Number.isNaN(minimumGasPriceTestnet)
) {
  throw new Error(
    'unable to retrieve network gas price from .gas-price-testnet.json',
  );
}
console.log(`Minimum gas price Testnet: ${minimumGasPriceTestnet}`);

The above script enables us to get the updated gas price from RSK Testnet, as minimumGasPriceTestnet.

The updated `hardhat.config.js` file:

Check out the full project source code on GitHub

const fs = require('fs');

require('@nomiclabs/hardhat-ethers');
require('@nomiclabs/hardhat-waffle');

const TESTNET_GAS_MULT = 1.1;

const mnemonic = fs.readFileSync('.testnet.seed-phrase').toString().trim();
if (!mnemonic || mnemonic.split(' ').length !== 12) {
  console.log('unable to retrieve mnemonic from .secret');
}

const gasPriceTestnetRaw = fs
  .readFileSync('.minimum-gas-price-testnet.json')
  .toString()
  .trim();
const minimumGasPriceTestnet = parseInt(
  JSON.parse(gasPriceTestnetRaw).result.minimumGasPrice,
  16,
);
if (
  typeof minimumGasPriceTestnet !== 'number' ||
  Number.isNaN(minimumGasPriceTestnet)
) {
  throw new Error(
    'unable to retrieve network gas price from .gas-price-testnet.json',
  );
}
console.log(`Minimum gas price Testnet: ${minimumGasPriceTestnet}`);

/**
 * @type import('hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: '0.7.3',
  networks: {
    rsktestnet: {
      chainId: 31,
      url: 'https://public-node.testnet.rsk.co/',
      gasPrice: Math.floor(minimumGasPriceTestnet * TESTNET_GAS_MULT),
      gasMultiplier: TESTNET_GAS_MULT,
      accounts: {
        mnemonic: mnemonic,
        initialIndex: 0,
        path: "m/44'/60'/0'/0",
        count: 10,
      },
    },
  },
};

3. Let's take a look at the concepts of hardhat tasks and plugins.

Hardhat is designed around the concepts of tasks and plugins. The bulk of Hardhat's functionality comes from plugins, which as a developer you're free to choose the ones you want to use in your project.

3.1. Tasks

Every time you run Hardhat from the CLI, you're running a task. e.g. npx hardhat compile is running the compile task.

3.2. Plugins

Hardhat does come with some built-in default plugins, all of which can be overriden. For this tutorial we are going to use the Ethers.js and Waffle plugins. They'll allow you to interact with Ethereum and to test your contracts. To install them in your project directory run:

npm install --save-dev @nomiclabs/hardhat-ethers ethers @nomiclabs/hardhat-waffle ethereum-waffle chai

4. Writing and compiling smart contracts

We're going to create a simple smart contract that implements a token that can be transferred. Token contracts are most frequently used to exchange or store value. Find below some logic we implemented by the contract.

There is a fixed total supply of tokens that can't be changed.
The entire supply is assigned to the address that deploys the contract.
Anyone can receive tokens.
Anyone with at least one token can transfer tokens.
Get Token balance of a given account

4.1 Creating the smart contracts

Start by creating a new directory called contracts and create a file inside the directory called Token.sol.

mkdir contracts
touch contracts/Token.sol
code contracts/Token.sol

Copy the below initial set up code for the Token transfer contract into your integrated development environment. We’ll implement the functions in the smart contract as we go along.

4.2. Code walkthrough

pragma solidity ^0.7.0;

import "hardhat/console.sol";

// This is the main building block for smart contracts.
contract Token {

    // Some string type variables to identify the token.
    // The `public` modifier makes a variable readable from outside the contract.
    string public name = "My Hardhat Token";
    string public symbol = "MHT";

    // The fixed amount of tokens stored in an unsigned integer type variable.
    uint256 public totalSupply = 1000000;

    // An address type variable is used to store ethereum accounts.
    address public owner;

    // A mapping is a key/value map. Here we store each account balance.
    mapping(address => uint256) balances;

    constructor() {
    // TODO set default candidates
    }

    function transfer(address to, uint256 amount) external {
    // TODO Create a function to enable transfer of Tokens
    }

    function balanceOf(address account) external view returns (uint256) {
        // TODO Create a function to check the balance of an account
    }
}

The first line - pragma - declares the version of Solidity you wish to write your code in. The declaration of the smart contract starts with the contract keyword, then the name of the contract. Here, Token is the name of our smart contract.

Next, we declare a string variable called name to hold the name and identifier for the Token. The line string public name = "My Hardhat Token"; declares a named variable that is public and of type string. This variable holds the identifier for the Token, which in our case is "My Hardhat Token"

Next, we declare a variable called "symbol" to hold the symbol for the token. The line string public symbol = "MHT"; declares a symbol variable that is public and of type string. This variable stores the symbol by which the token should be known, in our case "MHT".

Next, we declare a variable called totalSupply to hold the fixed amount of Token in circulation. The line uint256 public totalSupply = 1000000; declares a totalSupply variable that is public and of type uint (unsigned integer with 256 bits). This variable stores the fixed amount of tokens in supply, in our case is 1000000.

Next, we declare a variable called owner to hold the address of the owner of the contract. The line address public owner; declares an owner variable that is public and of type address.

4.3. Address data type

The address type comes in two flavours, which are largely identical:

address: Holds a 20 byte value (size of an RSK address).
address payable: Same as address, but with the additional members transfer and send.

The idea behind this distinction is that address payable is an address you can send RBTC to, while a plain address cannot be sent RBTC. Read more on Variable Declaration in Solidity

Next, we store each account balance in a key/value pair map. The line mapping(address => uint256) balances;maps an address field that stores the address of the account, and a uint256 field that stores the balance of Tokens in the mapped address.

The constructor function gets called when the smart contract is deployed to the blockchain. The constructor would be initialised upon contract creation. Read about Constructors in Solidity.

4.5. Implementing the smart contract functions

Implementing the constructor

constructor() {
        // The totalSupply is assigned to transaction sender, which is the account
        // that is deploying the contract.
        balances[msg.sender] = totalSupply;
        owner = msg.sender;
    }

The line balances[msg.sender] = totalSupply; assigns the address of the person deploying the contract to the balances address field, and then assigns the totalSupply to the uint256 field of the balances variable. The line owner = msg.sender; assigns the address of the person deploying the contract to the owner variable, which is of type address.

4.6. Transfer Function

function transfer(address to, uint256 amount) external {
        console.log("Sender balance is %s tokens", balances[msg.sender]);
        console.log("Trying to send %s tokens to %s", amount, to);
        // Check if the transaction sender has enough tokens.
        // If `require`'s first argument evaluates to `false` then the
        // transaction will revert.
        require(balances[msg.sender] >= amount, "Not enough tokens");

        // Transfer the amount.
        balances[msg.sender] -= amount;
        balances[to] += amount;
    }

The function transfer takes two parameters, the first is the address to which Tokens should be transfered to, and the second parameter is the amount of Tokens to be sent. The external modifier makes this function only callable from outside the contract. The functions requires that balance of sender should be greater than amount to be sent, if this condition is false, then an error message is thrown, saying "not enough Tokens". If the balance amount is greater than amount to be sent, then the amount is deducted from the senders balance and then credited to the receivers account.

4.7. Implementing the balanceOf Function

    function balanceOf(address account) external view returns (uint256) {
        return balances[account];
    }

The function balanceOf takes an address as a parameter and then returns the current balance of that address to the caller of the function. The view keyword in the declaration means that the function will not modify the state of the contract, while the returns keyword indicate that the function will return a uint256 value.

The updated Smart Contract

Check out the full project source code on GitHub

// SPDX-License-Identifier: GPL-3.0
// Solidity files have to start with this pragma.
// It will be used by the Solidity compiler to validate its version.
pragma solidity ^0.7.0;

import "hardhat/console.sol";

// This is the main building block for smart contracts.
contract Token {
    // Some string type variables to identify the token.
    // The `public` modifier makes a variable readable from outside the contract.
    string public name = "My Hardhat Token";
    string public symbol = "MHT";

    // The fixed amount of tokens stored in an unsigned integer type variable.
    uint256 public totalSupply = 1000000;

    // An address type variable is used to store ethereum accounts.
    address public owner;

    // A mapping is a key/value map. Here we store each account balance.
    mapping(address => uint256) balances;

    /**
     * Contract initialization.
     *
     * The `constructor` is executed only once when the contract is created.
     */
    constructor() {
        // The totalSupply is assigned to transaction sender, which is the account
        // that is deploying the contract.
        balances[msg.sender] = totalSupply;
        owner = msg.sender;
    }

    /**
     * A function to transfer tokens.
     *
     * The `external` modifier makes a function *only* callable from outside
     * the contract.
     */
    function transfer(address to, uint256 amount) external {
        console.log("Sender balance is %s tokens", balances[msg.sender]);
        console.log("Trying to send %s tokens to %s", amount, to);
        // Check if the transaction sender has enough tokens.
        // If `require`'s first argument evaluates to `false` then the
        // transaction will revert.
        require(balances[msg.sender] >= amount, "Not enough tokens");

        // Transfer the amount.
        balances[msg.sender] -= amount;
        balances[to] += amount;
    }

    /**
     * Read only function to retrieve the token balance of a given account.
     *
     * The `view` modifier indicates that it doesn't modify the contract's
     * state, which allows us to call it without executing a transaction.
     */
    function balanceOf(address account) external view returns (uint256) {
        return balances[account];
    }
}

4.8. Compiling contracts

To compile the contract, run npx hardhat compile in your terminal. The compile task is one of the built-in tasks.

$ npx hardhat compile
Compiling 1 file with 0.7.3
Compilation finished successfully

The contract has been successfully compiled and it's ready to be used.

Testing the smart contract

Writing automated tests when building smart contracts is of crucial importance. In our tests we're going to use ethers.js to interact with the RSK contract we built in the previous section, and Mocha as our test runner.

See the complete tutorial on the RSK Developers Portal showing examples for How to write and setup a testing environment.

Thanks for reading!

How to verify a smart contract on the RSK Block Explorer

Owanate Amachree — Tue, 18 Jan 2022 13:52:43 +0000

Originally published on the RSK Developers Portal.

Smart contracts are a means to execute code and store data on a blockchain.
To understand how smart contracts work, read What is a Smart Contract?

Source code verification provides transparency for users interacting with smart contracts. By uploading the source code, a block explorer will match the compiled code with that on the blockchain.

Once verified, a smart contract or token contract's source code becomes publicly visible and thus independently verifiable. This creates transparency and trust.
It also makes it more convenient for other developers to interact with your smart contracts.

In this tutorial, we will verify a smart contract, using the following steps:

Connect metamask to RSK Explorer
Get tRBTC using the RSK faucet
Use remix compile and deploy the Smart Contract at RSK testnet
Verify the Smart Contract on the RSK Explorer

Getting started

To connect Metamask to RSK Testnet, compile and deploy a smart contract, follow the steps in Using remix and metamask with RSK Testnet

As mentioned in the steps above, this is the smart contract below we will compile and deploy, it is called SimpleStorage.sol which has:

A variable storedData to store a number
A function get() to return the number stored at variable storedData
A function set() to change the number stored at variable storedData

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.7;

contract Contract {
     uint public x;

     constructor (uint _x)public{
        x = _x;
    }

    function increment() external {
        x++;
    }

    function add(uint one) external view returns(uint){
        // return the state variable
        return x + one;
    }
}

Prepare the compiler settings in Remix

In Remix, ensure that the compiler setting used for the contract is same as the one in Remix. In this tutorial, we used version 0.8.7 of the Solidity compiler, solc.

You do this by clicking on the solidity icon by the left navigation in remix, and selecting the compiler version, this looks something like: 0.8.7+commit.e28d00a7 in the dropdown menu.

Note that the exact version of the compiler,
plus the other details here are critical during verification.
We'll use this later.

Verifying the smart contract

Upon contract creation, you will receive an address to check a pending transaction. Visit the RSK Explorer and paste the transaction hash into the search field.

In this article, we'll use the transaction hash:
0x843c7fc61ef2d678b36bb6662f610426a60ca484443231c3347c1896e03dfd49

To verify the smart contract, we need to locate the contract address, to do this, scroll down to find the contract address.

Click on this address to open up the contract details.

Click on Code

This shows the bytecode for the contract.

If another developer sees this,
they are unlikely to be able to interact with your smart contract,
as this is not human readable.
Let's improve this by performing verification.

Smart contract code is usually written in a high level programming language such as Solidity.
This code gets compiled to something called the bytecode which gets deployed to the RSK blockchain.
The nodes that comprise the RSK blockchain network execute this bytecode.
What is actually stored on the blockchain is not the original code written in Solidity,
but rather this compiler output.

Click on Verify Contract

Fill in the details below, enter contract name, upload the source file called SimpleStorage.sol.

Check that the compiler version matches the version selected in remix, as shown in the images below;

Fill other info, such as constructor arguments, libraries, and EVM encoded arguments (if available).

Note that the SimpleStorage.sol smart contract
does not have any constructor arguments, so this is left blank.

Click on Verify.

Contract successfully verified.

Once contract is successfully verified, click on "go to contract page". You'll notice a checkmark is now present beside Code which wasn't there previously.

You can click on it to see more details of the contract.

You'll also be able to see the compiler settings.

Congratulations, you have successfully verified a smart contract on the RSK Block Explorer. To see a live example check out the one used in this article:
0x111b836d63e507a45dee556b10aa17ef16d423ae.

The A-Z of Stablecoins

Owanate Amachree — Wed, 29 Dec 2021 14:00:50 +0000

Originally Published on Hackernoon

Centralization runs deep in society in the form of corporations, businesses and governments. Not that they’re bad, but blockchain technology can offer a viable structural alternative by creating a more transparent and accountable system. The idea of open-source decentralization is to redistribute power and to create a fair and trustless system across all industries. This technological breakthrough, therefore, brings lots of promise and hope for the future.

The inception of Bitcoin in 2009 has resulted in a revolution in the trading and payments industries. People have started to accept cryptocurrencies as a form of payment and it’s being exchanged in large volumes. These can be used for global transactions, buying new assets, and at your nearby retail stores.

Even though many stores accept Bitcoin and other tokens as a method of payment, it’s rare to see token holders use it in their daily transactions. Another argument might be that there aren’t enough shops that accept it. An often cited reason behind this is that it’s not practical to use it as a unit of account. Stablecoins are tokens developed for this particular reason. They are termed “stable” because they are pegged to the value of something else, such as precious metals or fiat currency.

To better understand stablecoins, it is important to first learn about price volatility in cryptocurrency.

Volatility is a measure of how much the price of an asset has moved up or down over time. There are many factors attributing to the volatile nature of Cryptocurrency. Firstly, Cryptocurrency is still at a very nascent stage compared to other investment tools, traditional currencies and even gold. Secondly, the cryptocurrency market thrives on speculation, traders bet that the prices would go up or go down to make profits. These speculative bets can cause a sudden influx or a sudden efflux, leading to high volatility. Their highly speculative nature might be an attractive feature for investors, but it also makes them hard to use in payments and trade. Compared to other cryptocurrencies, stablecoins are stable in value while maintaining similar decentralized features as cryptocurrencies. This makes them an ideal medium for value storage or transaction.

What are Stablecoins?

A stablecoin is a token built on a blockchain network that is designed to minimize volatility by pegging to a more stable asset. Most commonly, they are backed by US dollars, but they can also be backed by other fiat currencies, like euros or yuan, and even assets like gold, or other cryptocurrencies. Benefits of this include being able to take advantage of blockchain technology and peer-to-peer value transfer while not being exposed to the high price volatility of Bitcoin, Ether, or other cryptocurrencies. Stablecoins are a relatively new kind of technology and each of them comes with different implementations, liquidity, risks, and acceptance.

Importance of Stablecoins

Without both short-term and long-term stability, it is considered extremely risky for the mainstream public to adopt cryptocurrencies as a direct replacement for fiat or traditional assets. Larger mass adoption will always require some form of stability. From a consumer perspective, it’s risky and impractical to use cryptocurrencies and tokens for daily use. A volatile medium of exchange can compromise users' purchasing power.

That’s where stablecoins are the go-to. Stablecoins are the only form of tokens where you don’t have to worry about the instability and volatility of cryptocurrency prices. Stablecoins have an important role due to the following factors:

Protection from (hyper)inflationary fiat economies Stablecoins have the potential to help people living in countries suffering from high inflation rates, which ultimately reduces their purchasing power. This is usually a result of economic and political uncertainty. There are many examples throughout history where fiat money has significantly suffered from devaluation.

In these countries, it is extremely hard to move their capital elsewhere since capital control laws are imposed by the government to prevent money from leaving the country. Converting their money in stablecoins will ensure that the value of their money is preserved, instead of keeping their money in their national fiat currency which will further reduce their purchasing power. Stablecoins have the ability to globally assist the masses from the fallout of economic and political uncertainty.

Hedging Mechanism For Traders

To hedge is to reduce the risk of adverse price movements in an investment or asset. Hedging is a strategy often used in the investment world to protect users' positions by reducing risks. Stablecoins are commonly used in the cryptocurrency market as a hedge against Bitcoin and other digital assets. Converting their holdings into stablecoins protects their value.

Types Of Stablecoins

There are several ways that the stability feature of stablecoins are designed. The two most common types are convertible and synthetic stablecoins. The key difference between these two is how they are collateralized.

Convertible stablecoins These are backed by assets that are held in a reserve, where the asset acts like an IOU that is held by a centralized entity. The most commonly used are fiat-backed stablecoins pegged to the US dollar like USDT or USDC.

For a more detailed explanation about Stablecoins, Read more in What are Stablecoins?

Synthetic stablecoins

They aim to target a return to a reference sovereign currency like the USD, but they are not directly convertible for fiat currencies.

One way to achieve the target stability is by using crypto-collateralization (for example, DOC or RDOC), or using derivatives (eg XUSD). Another way is through a peg that is actively managed using an algorithmic monetary policy or smart contract (eg Terra or Ampleforth). This is often used in conjunction with oracles that provide on-chain access to price feeds for fiat and blockchain asset pairs.

See the Difference between Stablecoins and other Digital Assets
Stablecoins on RSK

Stablecoins play an important role in the RSK ecosystem:

They allow users to send, receive, or save the value in a stable form
Offer a stable trading pair for swaps
Stablecoins function as less volatile collateral for borrowing reducing the risk of a margin call
Create more stable yield generation and they're part of the foundation for RSK’s DeFi on Bitcoin ecosystem.

Bitcoin-backed Stablecoins

DOC

DOC is short for Dollar on Chain. DOC is 100% collateralized with Bitcoin, with a 1:1 USD peg guaranteed by the smart contract. Dollar on Chain is the ideal stablecoin for daily transactions and users seeking to hold current value without leaving the benefits of bitcoin.

The DOC Token Smart Contract Address: 0xE700691Da7B9851F2F35f8b8182C69C53ccad9DB

Features

Self Contained in the Blockchain
What makes DoC unique is that the collateral is in a Smart Contract inside the blockchain, this means you don't need to trust a third party controlling the collateral.
Perfect for Daily Transactions
With third party non-custodial wallets you can instantly send and receive DoC with no protocol fees.
Personalized Wallet Storage
Forget about giving up your private keys to a third party, DoC tokens are securely stored in your own wallet.

Benefits

Users of the DOC tokens gain;

Best Collateral

Dollar On Chain doesn’t rely on fiat. All the collateral is bitcoin. The DoC's outstanding stability is guaranteed by the Smart Contract.

Buy or Mint
You can buy DoCs on a secondary market, but the Smart Contract allows you to mint your own DoCs avoiding unnecessary extra costs such as the spread.
Use for Daily Transactions
DoC is fast, secure and it doesn't have any protocol fees. That's why there is a growing ecosystem around it.

Where to Get DOC Tokens?

You can get the DOC on Money On Chain Stablecoin Protocol or read the Getting Started Guide.

RDOC

The RIF Dollar on Chain stablecoin, or RDOC for short, is one of the main assets on the RIF On Chain DeFi platform. RIF on Chain is powered by Money on chain, a stablecoin and leveraged token protocol, which runs on RSK smart contracts.

RDOC is a stablecoin in the RSK ecosystem that's pegged 1:1 to the US Dollar and guaranteed by a smart contract.

RDOC is a crypto-collateralized stablecoin that uses the RIF token as collateral.
Unlike the majority of other DeFi protocol stablecoins where users are required to provide collateral or a collateralized debt position to borrow funds, like the competing Ether-backed decentralized stablecoin DAI, RDOC can be acquired by platform users directly by spending RIF, which is a unique feature that some users may prefer.

The RSK Infrastructure Framework is creating the building blocks to construct a fully decentralized internet that enables decentralized sharing economies.

An important distinction to keep in mind is that RBTC is the transactional token that facilitates operations on the RSK network, whereas the RIF Token allows any token holder to consume the services that are compatible with the RIF architecture.

Avoid crypto volatility using RDOC for payments, daily transactions, holding your savings, and acquiring RIF Services like identity, storage or communications.

RDOC smart contract token address: https://explorer.rsk.co/address/0x2d919f19d4892381d58edebeca66d5642cef1a1f

How to Get RDOC?

Buy RDOC using a Decentralized Exchange

You can buy RDOC tokens on a DEX, such as RSKSwap or https://tex.moneyonchain.com/, and Liquality Swap .

Minting RDOC

You can mint the tokens yourself using RIF as collateral. To mint RDOC, you need to connect to the RIF On Chain Platform. You can access the RIF On Chain Platform at https://rif.moneyonchain.com.

Note, before you can interact with the ROC platform, you need to:

Set up an RSK network-compatible wallet like Nifty Wallet, Wallet Connect, Metamask, or Liquality
Fund your wallet with RIF for minting, and RBTC to pay for gas fees.
Mint RDOC through the MINT/REDEEM button on the Exchange section of the RIF On Chain Platform, and you'll need to set the ALLOWANCE regarding the amount of funds in the wallet that you authorize to spend on minting. Note, the platform charges a fee of 0.1% of the value in RIF.
After you confirm the mint, your RDOC balance will be reflected within a few seconds and you have access to a USD pegged stablecoin on the RSK network

XUSD

BabelFish is the cross-chain protocol that aggregates stablecoin liquidity from multiple issuers and chains into one single token: XUSD.

XUSD is a USD-pegged stablecoin that acts as a decentralized aggregator and distributor of different stablecoins. XUSD can be exchanged and redeemed 1:1 with any of the underlying stablecoin tokens backing it using smart contracts.

BabelFish acts as a decentralized bank that has branches on different chains, accepting and distributing USD-pegged stablecoins. In this way, it acts as a "trustless stablecoin translation device" for supported stablecoins on different networks.

Why Use XUSD?

XUSD is a unique stablecoin: by acting as a decentralized aggregator and distributor of different stablecoins, it offers three advantages:

Reduces risk: Pooling liquidity from multiple networks reduces potential systemic risk across platforms and marketplaces if one stablecoin is compromised. Users of XUSD are also subject to less systemic risk because the Babelfish insurance fund is intended to provide a level of security beyond the assurances offered by its underlying stablecoins.
Provides deeper liquidity: The advantage of this type of architecture is that it allows the fragmented liquidity pools formed by various stablecoins to join together as one larger and thus more liquid stablecoin pool. Deeper liquidity leads to lower slippage or failures in closing margin and lending positions. Deploying XUSD on top of the RSK network also attracts liquidity to the RSK ecosystem.
Provides flexibility: XUSD facilitates a 1:1 exchange between different stablecoins and networks. It allows users to easily bridge multiple stablecoins from RSK, Ethereum, & Binance Smart Chain networks to XUSD, and in reverse.

XUSD currently serves the following use cases:

International remittances and payments
Stable collateral in RSKs DeFi on Bitcoin ecosystem
Open margin trades using XUSD or swap between XUSD and other tokens
Lending to earn interest on XUSD, including the option to earn interest in RBTC and FISH tokens
Use it to save as a non-volatile store of value

Need help storing Stablecoins? Read How to Store Stablecoins on RSK

How to Get XUSD?

On an Exchange

A Decentralized exchange like RSKSwap, TEX, or Sovryn Swap
Use a swap app to exchange your crypto for XUSD, like Liquality Swap.
Peer to peer through Defiant or another user like you.

Use a Bridge

You can use a cross-chain bridge. The BabelFish Bridge allows easy and permissionless transfers of tokens from one chain to another through audited smart contracts.

There are 3 networks included in the Cross-Chain Bridge: RSK, Ethereum, and Binance Smart Chain. You can use the BabelFish Bridge to cross funds in and out of RSK with the Ethereum and Binance Smart chains.
The bridge allows users to transfer multiple stablecoins from Ethereum and BSC to RSK XUSD. The $XUSD tokens on RSK can be bridged into any of the supported stablecoins at a 1:1 ratio.

XUSD smart contract token address: https://explorer.rsk.co/address/0xb5999795be0ebb5bab23144aa5fd6a02d080299f?__ctab=general

Find out more in the Stablecoins on Bitcoin .

RBRZ Tokens

RBRZ is the first Brazilian stablecoin in circulation. 1:1 pegged to the Brazilian Real. It will allow Brazilians to directly ramp up investments in foreign exchanges and to trade a Brazilian Real (BRL) pegged stablecoin on a global scale. It will permit sending and receiving BRL backed tokens safely and instantly, for a fraction of the cost of any other alternative.

Features

Stability

Price stability will be pursued by market agents based on the reserves held by the Reserve Managers.

Reserve

The Reserve Managers keep full reserves. BRZ Tokens are always fully backed.

Multichains

The BRZ is built-up on top of Ethereum, Solana and Algorand blockchains.

Security

The BRZ Smart Contract is the public instrument used for issuing and burning tokens according to convertibility demands. Our crypto transactions are verified by Parsiq.

Transparency

The issuance of new tokens and the underlying reserves will be audited by a reputable third-party firm.

Global Acceptance

The BRZ Token can be traded on multiple platforms.

Why Use BRZ?

Access to International Platforms
Brazilian users now can enter international crypto markets without immediate exposure to Bitcoin or any other volatile cryptocurrency.

Enter the Brazillian Market
International exchanges and platforms will be able to enter the Brazilian market seamlessly. Acquire Brazilian customers with a frictionless solution.

Trading Opportunity
Users will be able to trade 24h / 7 days.

Hedge
International investors with business in Brazil will have an easy alternative to hedge their holdings in Brazilian Reais.

How to Get RBRZ?

To get BRZ, use the RSKSwap

Ethereum-based Stablecoins

The RSK ecosystem allows users an alternative way to transact with Ethereum-based stablecoins like USDT or DAI with much lower fees by converting them to stablecoins that move on the RSK network, including rUSDT, rDAI, and others.

RBRZ Smart Contract Address: https://explorer.rsk.co/address/0xe355c280131dfaf18bf1c3648aee3c396db6b5fd

rUSDT

rUSDT is the RSK token bridge "crossed token" counterpart to USDT, which is natively from ethereum.
Tether USDT converts cash into digital currency, to anchor or tether the value to the price of national currencies like the US dollar, and the Euro.

Tether token is also 1-to-1 pegged to the dollar, so 1 USDT Token is always valued by Tether at 1 USD.

Read the Tether Whitepaper: https://tether.to/wp-content/uploads/2016/06/TetherWhitePaper.pdf

Ethereum/RSK Bridge that allows to move ERC20 tokens between one chain and the other. The bridge contracts are upgradeable, this enables a smoother move to a more decentralized bridge in the future.

rUSDT smart contract token address: https://explorer.rsk.co/address/0xef213441a85df4d7acbdae0cf78004e1e486bb96

How to Get rUSDT?

Using a Swap app;

To get rUSDT, use the RSKSwap

Using the TokenBridge;

You can use the ‘Token Bridge DApp’ together with Nifty Wallet or Metamask to move tokens between networks.

Follow the Dapp guide for more details on how to use the token bridge.

Find out How to Get Stablecoins on RSK

rDAI

rDAI is an alternative to convert Dai and pay much cheaper transaction costs, around 0.15c per transaction which is approximately 80 times cheaper than transacting DAI compared to doing it over the Ethereum network.

Why use rDAI?

Boycott High Fees on Ethereum
Ethereum is experiencing extraordinarily high fees which make it impractical & expensive for most use cases.

How to Get rDAI?

Want to convert your DAI to rDAI?

Cross DAI to rDAI using the Defiant or Token Bridge

Cross DAI to rDAI using Kripton Market Swaps on Defiant or follow the Step by Step Guide

rDAI smart contract token address: https://explorer.rsk.co/address/0x6b1a73d547f4009a26b8485b63d7015d248ad406

See more explanation in Understanding Cross-Chains: How to use the RSK TokenBridge

For a more detailed explanation about Stablecoins, the differences between stablecoins and other types of digital assets, stablecoins on Bitcoin, where to store them, how to cross stablecoins using the RSK Token Bridge, and how blockchains achieve interoperability via cross-chain bridges, check out The Complete Guide to Stablecoins on the RSK Developers Portal!

Resources

Thanks for reading!

RSK Community Call, December 2021 - Summary

Owanate Amachree — Mon, 20 Dec 2021 14:09:57 +0000

About the next hard fork HOP & RSKj Iris v3.2.0, Simplified Emergency Time-locks Refresh, Bridge peg-out Batching..

On 16th December 2021, The RSK Ecosystem held its fifth community call. The aim of these community calls is to discuss the RSK Improvement Proposals - RSKIPs, get the community involved, gather feedback, discuss the RSK consensus protocol, the formal process for proposing improvements, and the upcoming network upgrades. For more info, read the RSKIP Purpose and Guidelines.

It was live-streamed on several platforms, thanks to everyone who joined the Livestream! For those of you who missed out on attending it live, visit the links below;

🎥 Watch the RSK Community Call December 2021 on Youtube (Replay).

🗣️ Propose your own RSKIPs

🔗 Join the RSK Research & Innovation Forum

🗣️ Suggest RSKIPs to discuss in the next community call

🔗Join our Open Slack Community and ask your questions in #research-and-innovation.

The speakers on this call were:

Adrian Eidelman
Sergio Demian Lerner
Marcos Irisarri
Brendan Graetz

In this call, we discussed:

The RSKj IRIS v3.2.0

Adrian Eidelman gave brief updates on the next release of RSKj. He said the IRIS v3.2.0 will happen in early January 2022. The new version will contain several improvements to the JSON-RPC interface (e.g, the pending argument for getBlockByNumber), improved gas estimation, support for new methods specifically support for new arguments that were not supported in already existing methods for. Also, there will be various performance improvements.

He pointed out that all these changes are non-consensus changes, so this release is not a mandatory upgrade for RSK Mainnet. There are improvements being made to adjust the minimum difficulty for users and developers working on RSK Testnet. This does constitute a consensus change only for the RSK Testnet. Thus v3.2.0 of RSKj will be a mandatory upgrade for RSK Testnet.

See related links:

The next hardfork: HOP

Adrian Eidelman also talked about the next hardfork named HOP, though the date for this hardfork has not been set yet, he said this is open for discussion, and anyone can post their proposals to be discussed and included in the next hardfork via the RSKIP 291: Network Upgrade HOP Initial Proposal.

He said two improvements were proposed which are Peg-out Batching and Simplified Emergency Time-locks Refresh. Read more about these proposals in Network Upgrade RSKIP. These same proposals were subsequently discussed in more detail.

Simplified Emergency Time-locks Refresh

Sergio Lerner talked about the Simplified Emergency Time-locks Refresh, he started with a brief recap of the history of what is now the RSK PowPeg, the potential problems with the PowHSM and the solutions introduced by RSKIP-201. He talked about the activation of the emergency multisig and that it has been ready since the IRIS network upgrade proposed in Jan, 2021 and activated in Aug, 2021 but it only activates after the first change in the powpeg members and that we have delayed activation because there was no automatic method to refresh the UTXOs (only manual refresh) and that the RSKIP-264 (Simplified Emergency Time-locks Refresh) proposes such a method. The Emergency multisig will be activated with a PowPeg renewal immediately after RSKIP-264 is activated.

He highlighted the features of RSKIP-264:

Checks all UTXOs for timelock expiration every 2 weeks
Renews the time-locks 6 months prior to the expiration
Compete renewal of all UTXOs every 6months
Low expected average load
Best efficiency if RSKIP-270 (Bridge UTXO set size management) is activated

See related links;

RSKIP 270 - Bridge UTXO set size management

RSKIP 271 - Bridge peg-out Batching

Marcos Irisarri talked about the bridge peg-out batching. He said the idea is to reduce the cost for users when performing peg-out transactions while maintaining security of the peg.

He talked about the current peg-out process;

RSK user sends n RBTC to the Bridge contract address
Bridge smart contract creates a BTC transaction sending n BTC to the user’s derived BTC address
Wait 4000 RSK blocks confirmations (33 hours approx) then the PowHSM signs the transaction
User receives the amount sent to the Bridge minus the BTC transaction fees

The proposal is to;

Each time a user sends RBTC to the Bridge, the peg-out request is added to a queue
Every 360 RSK blocks (approximately 3 hours) the Bridge creates one BTC transaction with an output for each of the peg-out requests in the queue
Wait 4000 RSK blocks confirmations (33 hours approx) then the PowHSM signs the transaction
Each user receives the amount sent to the Bridge minus a fraction of the BTC transaction fees

He also highlighted the pros of the bridge peg-out batching, which includes less fees to be paid by users (total fee is divided among all the users receiving funds), and the pros involved. These include additional waiting time for the user to receive the funds (9% increase). This time has the potential to be reduced to 16 hours approximately in a following network upgrade.

See related links;

RSKIP 271 - Bridge peg-out Batching

Decisions

No decisions were made during the December Community Call.

However, there was a short debate about RSKIP-271:

Brendan raised the question about whether both RSKIP-271 and the RSKIP that would halve the waiting time could be both included in HOP, or whether the latter needed to be in a separate network upgrade.
Sergio raised the question about whether RSKIP-271 could be implemented without necessitating a network upgrade in the first place, by avoiding consensus changes.
These questions were not resolved during the call, and thus the discussion continues in the RSK Research forums

Summary

For more details on these, please watch the recording on Youtube.
Want to champion an RSKIP? Missed the previous RSK Community Call? Watch the recording on Youtube. Also, leave a comment on this thread for the next community call!

Resources

Thanks for reading!

RSK Community Call - October 2021 Summary

Owanate Amachree — Mon, 08 Nov 2021 12:52:29 +0000

About RSKj v3.1.0, Aggregation & parallel transaction processing, and Rollup-optimized Ephemeral Call data.

On 29th October 2021, The RSK Ecosystem held its fourth community call. The aim of these community calls is to discuss the RSK Improvement Proposals - RSKIPs, get the community involved, gather feedback, discuss the RSK consensus protocol, the formal process for proposing improvements, and the upcoming network upgrades. For more info, read the RSKIP Purpose and Guidelines.

It was live-streamed on several platforms, thanks to everyone who joined the Livestream! For those of you who missed out on attending it live, visit the links below;

🎥 Watch the RSK Community Call October 2021 on Youtube (Replay).

🗣️ Propose your own RSKIPs

🔗 Join the RSK Research & Innovation Forum

🗣️ Suggest RSKIPs to discuss in the next community call

🔗Join our Open Slack Community and ask your questions in #research-and-innovation.

The speakers on this call were:

Diego Masini
Adrian Eidelman
Sergio Demian Lerner
Brendan Graetz

In this call, we discussed:

The recent RSKj v3.1.0 release
Aggregation: fast and cost-effective peer-to-peer payments
Parallel transaction processing: block processing as fast as possible
RSKIP-281: Rollup-optimized Ephemeral Calldata

The RSKj v3.1.0 Release

Adrian Eidelman talked about the release of RSKj v3.1.0. He said this release contains several enhancements in JSON-RPC interface, Ethereum compatibility fixes and node performance improvements, among other things. Also, some of the improvements introduced in this release came from community contributions made within the past RSK Hackathon: Building the Future On Bitcoin on the Gitcoin platform.

This release is a non-mandatory upgrade, however, you should consider updating to benefit from the enhancements and new features.

See related links:

See more details about the RSKj v3.1.0 release milestone
Releases page

Aggregation: fast and cost-effective peer-to-peer payments

Diego Masini spoke about the work done on Aggregation, which is a fast and Cost-effective payment system. He said it is a layer 2 scalability solution for RSK and its main goal is to process transactions off-chain, bundle them in batches and post a validity proof for these batches to the blockchain. This solution ensures that the layer 2 transactions are secured by the blockchain and we can transact much faster. He mentioned two potential approaches to this solution which includes; optimistic rollups and Zero-Knowledge (ZK) rollups, he said the method of verification between these two approaches is the key distinction.

Parallel transaction processing: block processing as fast as possible

Diego Masini also spoke about the ongoing work on parallel transaction processing, which enables processing a block as fast as possible. This enables transactions to be split into different partitions, and each partition could be executed in parallel. The main goal of this approach is to process as many transactions per block as possible and also reduce synchronization time.

RSKIP-281: Rollup-optimized Ephemeral Call data

The RSKIP-281 is an improvement over RSKIP214 and RSKIP28. It enables sending data to contracts called ephemeral data and enables the disposal of this data at a later block.

Sergio Lerner introduced the RSKIP-281. He noted that this research began in 2016 and it is about the optimization of the RSK blockchain to better serve as a data availability layer for rollups. He said this proposal is very efficient and can provide gas savings for rollups such as Aggregation. An ephemeral call data, is similar to the call data, but gets a discount in gas costs because it is only temporarily available for smart contracts to query. The use cases for this kind of data is;

Data to be challenged over a period (optimistic computations)
Immediate availability of datasets that accept a later compression

Both occur in Zero Knowledge (ZK) and Optimistic Rollups

He mentioned two flavours of this type of data;

Remove by Default (initially cheap, pay more to preserve data)
Keep by Default (initially expensive, with reimbursement on data removal)

He said there are many advantages of using rollups;

This includes freedom to experiment, inheriting layer 1 security, the ability to create governance tokens, etc, this allows for easy collaboration and integration of different needs.

He compared the gas costs of transferring tokens for several existent rollups, such as Arbitrum ZK-Sync, Fuel, etc.

He explained how the Ephemeral Call Data is implemented by creating a new field in an RSK transaction. He said this field contains other fields and that instead of the ephemeral call data (ecd) being hashed into the transaction, it is being double-hashed. This double hash gives the opportunity to remove the original data without changing the transaction ID. He explained other fields like the ecdSize, ecdHash, hasherContractAddress, hasherCallGasConsumed, etc as captured in the image above.

See related links:

RSKIP-281
Discuss RSKIP-281 for Ephemeral Call Data

He summarized his talk by saying, the ephemeral Calldata reduces the cost of Rollups realistically (compared with the unrealistic reduction in the case of Ethereum), it can be removed by default, or kept by default. It also requires changes on several parts of a consensus protocol, and it competes with other RSKIPs, such as RSKIP-215 (Ephemeral Blockchain).

Decisions

No decisions were made during the October Community Call.

Summary

For more details on these, please watch the recording on Youtube.

Want to champion an RSKIP? Missed the previous RSK Community Call? Watch the recording on Youtube. Also, leave a comment on this thread for the next community call!

Resources

Thanks for reading!

Fungible Token Standards

Owanate Amachree — Fri, 24 Sep 2021 12:16:10 +0000

ERCs vs EIPs vs RSKIPs

Ethereum Requests for Comment (ERCs),
and Ethereum Improvement Proposals (EIPs)
refer to the same thing - they were originally called ERCs,
and then subsequently renamed to EIPs.
These are all focused on improvements to Ethereum.

RSK Improvement Proposals (RSKIPs) use a similar process to improve RSK.

A small subset of EIPs, albeit an extremely popular subset,
are tokens standards, which have to do with smart contracts,
and do not have much to do with the Ethereum nodes.
Instead, they focus on the Solidity smart contract implementations
with the intent to standardise the ways in which tokens get implemented.

Ethereum Token Standards work on RSK

Since the RSK Virtual Machine (RSKVM) is compatible with
the Ethereum Virtual Machine (EVM) at the op-code level,
smart contracts that are compiled to target the EVM
can be executed in exactly the same way on the RSKVM.

Note: Some differences exist, most notably to do with how gas
costs are calculated, both in terms of the schedule per op-code,
as well as the calculation methodology.
At the time of writing, like-for-like smart contract function invocations
cost 2% to 2.5% on RSK compared to Ethereum.

Owing to this level of compatibility,
the same smart contracts standards that work on Ethereum
also work on RSK - there is no need to create "mirror RSKIPs"
that are the equivalent of EIPs for token standards,
since they will be virtually identical.

Fungible Tokens

address -> amount

At their core, fungible tokens are smart contracts which store
a mapping of addresses to amounts.
This is used to represent an understanding that each particular address
is the owner of a particular amount of tokens.

transfer(...)

These smart contracts will also have a transfer function,
that allows them to transfer the tokens held in one address to another address.

Of course, there is a lot more to fungible tokens than the above,
the above is merely a rudimentary illustration.

ERC20

The ERC20, or EIP20, token standard is the most well-known
among all fungible tokens standards.
In fact, it was so popular, that at some point 3 in 4 smart contracts on the Ethereum blockchain implemented this standard.
To this day, it remains a dominant force,
and in fact the term "ERC20" is almost synonymous with the term "fungible token".

The above is also true on the RSK network,
virtually all fungible tokens implement this particular token standard.

Its continued relevance stems from the fact that whenever
a new fungible token standard comes out,
the most critical factor to enable adoption is to be "ERC20 compatible".
This means that new fungible tokens standards implement
the interface specified by the ERC20 token standard,
and then add their own additional functions on top of it.

ERC677

The ERC677 token standard is also a fungible token standard,
and it extends the ERC20 token standard.

transferAndCall(...)

The key addition is the transferAndCall function,
which allows the user to combine
a transfer function invocation on the fungible token smart contract
with another function invocation of their choice on a different smart contract.
This allows the user to accomplish both operations in a single transaction
submitted to the blockchain network.

On the RSK network, the LINK token from Chainlink,
and the RIF token from RSK, both implement this standard.

More standards

There are many other smart contract standards
used to build fungible tokens, including ERC223, ERC777, and ERC1363.
These all happen to be backwards compatible with ERC20 standard,
however have not seen much by way of widespread adoption yet.

Thanks to Brendan Graetz for writing this article!

Decentralised Wallets-DeFi Gateways

Owanate Amachree — Thu, 23 Sep 2021 01:22:56 +0000

Decentralised Finance (DeFi) has been a hot topic for a number of years and continues to draw attention, resources and innovation from all corners of the world. This article aims to give information to those who are interested in delving deeper into accessing this exciting universe of decentralised applications, where bunnies with pancakes on their heads and unicorns come with the territory.

Decentralised wallets, also labelled as DeFi wallets, are the gateways into these vast ecosystems of decentralised applications otherwise known as dApps. As a basis, a wallet is a service that enables a user to store their digital assets and is available under two structures: centralised and decentralised.

Centralised and decentralised wallets

Most of us are familiar with a centralised authority acting as the custodian (or keeper) of our assets, this holds true in the traditional markets (for example, banks) and with digital assets with the most common being centralised exchanges like Coinbase, Binance, Bitstamp and so on. In fact, centralised exchanges are a starting point for many to move funds from fiat to crypto and then make their way into the DeFi ecosystem.

With decentralised wallets, the user self-custodies the funds keeping full ownership, responsibility and control of the funds within. These typically come in the form of software wallets — as browser extension and/or application download — and as a physical hardware device. This article is primarily focused on software wallets which are the most commonly used wallet to connect to dApps and I discuss how hardware wallets can be used with software wallets to exponentially enhance security.

	Centralised Wallets	Decentralised Wallets
Control	Centralised entities have an immense amount of control over a user's account and could perform an action such as locking access to it. Importantly, you do not own your private keys (more on private keys and seed phrases later).	With self-custody comes the complete control over your funds and ownership of your private keys.
Security	Vulnerable to hacks and as we see more money flow into this space, there will be greater motivation for malicious actors to focus on vulnerable points of entry to gain access to users’ funds. Although the risk remains, security procedures are continually evolving and the most trusted exchanges strive to be ahead of the security curve.	Exploits typically occur by gaining access to your password or seed phrase by hacking your computer or through social engineering.Never give anyone your password or seed phrase, and store them offline (preferred) or through a trusted password keeper. To enhance security, use a hardware wallet in conjunction with your software wallet (I’ll explain this further).
Convenience	Should you forget your password, the entity can help you recover it via some form of authentication.	Should you forget your password and misplace your seed phrase, your funds are unrecoverable.
Features	Most users will use a crypto exchange to store their funds (fiat and blockchain assets) which opens up the features we are accustomed to from exchanges such as trading - in the spot and margin markets - across order types. Depending on the exchange, additional features like lending, staking and prediction pools may also be available.	Does not hold fiat but stores blockchain assets which include stablecoins. Although there is constant innovation, the main feature is their ability to connect to dApps, which opens up the true power of DeFi.
Regulations	Entities are becoming increasingly regulated and new laws/regulations will continue to impact their operations and therefore, their users.	There is mention of regulation which is largely focused on the dApps, however, no noteworthy news has been released which would impact users to date on decentralised wallets.
KYC (Know your customer)	Must follow KYC procedures (typically proof of identity and address) to ensure compliance in the jurisdictions they have operations in.	No KYC required.
Examples	Centralised Exchanges: Coinbase, Binance, Bitsamp, Luno	Software wallets Browser Extension: Metamask, Trust Wallet, Liquality App Download: Metamask, Edge, Eidoo, Argent Hardware wallets: Trezor, Ledger, D’CENT

Passwords and seed phrases / private keys

As mentioned, should you forget your password, there is no entity to interact with in order to recover it. The user needs to store their password and seed phrase preferably offline. A seed phrase (also called a recovery phrase) is your encrypted private key that are typically represented as a string of words that you can input should you forget your password and/or lose access to your wallet. Losing your seed phrase will result in your funds being unrecoverable!

To understand these concepts better, this article by lykke.com does a brilliant job of explaining it by using your home as an analogy.

For optimal security, there is a recommended approach that utilises a hardware wallet to store your private key offline. Many software wallets, for example Metamask — the most widely used decentralised wallet — offer integration with hardware wallets like Trezor and Ledger, ensuring maximal security with the flexibility of transacting on decentralised applications. With this integration, every time the user needs to transact on an application, they will require their connected hardware wallet to approve the transaction, which requires a physical touch sequence on the hardware wallet.

The key takeaway is that decentralised wallets are the gateways into interacting with decentralised applications across the blockchain spectrum. This is where the power really tilts in the favour of users who choose to self custody their funds.

Some applications that are worthy of mention are Aave and Compound, who are in the business of lending/borrowing, as well as Uniswap, Sovryn and Pancakeswap, who are primarily focused as decentralised exchanges (DEXs) — where you can swap between a vast array of crypto currencies and stablecoins.

The examples above are just the tip of the proverbial iceberg[1] as there are a myriad of decentralised applications which span a host of blockchains (blockchains like Ethereum, Binance Smart Chain, RSK and Solana to name a few) and the user can connect to them through their decentralised wallet.

What software wallet is best for me?

After reading this article you may have questions regarding what is the best software wallet for you to use as there are a number of options. Remembering that software wallets cover browser extensions and/or application download. In order to keep the focus, I’ll dedicate a separate post to wallet options as it is heavily dependent on a number of factors, one of which is which blockchain you are looking to interact with.

Where to go from here?

Software wallets have been evolving their value proposition with one example being Liquality, where one can store their favourite digital assets and perform an atomic swap (peer-to-peer cross blockchain exchange of one cryptocurrency for another without trusted third parties). This is powerful as one can exchange a cryptocurrency on one blockchain for example ETH (on the Ethereum blockchain) to a completely different asset for example RBTC (the Bitcoin pegged native currency on the RSK blockchain). This is a fantastic use case for anyone looking to move their funds to a different blockchain so they can then interact with those new and exciting dApps!

This post is not to say that decentralised wallets are better than the centralised equivalents. Both structures can (and do) co-exist and provide access to services in differing ways. The goal of this post is to give insight into the growing DeFi ecosystem which, as of writing, sits at $120 billion dollars in market capitalisation with decentralised wallets being the entry point.

Have you been impressed by any wallets, be it software or hardware?

Leave a comment or reach out to discuss!

Footnotes

[1] Be careful out there. Although the innovation is astonishing, hacks are frequent in this space and not all dApps are considered ‘safe’.

Legal disclaimer: The post above does not constitute financial advice. It is very important to do your own analysis/research before making any investment and base this on your own personal circumstances.

Article originally written and published on Medium by Michael Mendez

RSK Community Call - August 2021 Summary

Owanate Amachree — Thu, 02 Sep 2021 09:05:48 +0000

_About expanding the emergency multi-sig, peg-out tx fee-bumping, time-lock refresh, bridge UTXOs selection, consolidation, and batching.

On 19th August 2021, The RSK Ecosystem held its third community call. The aim of these community calls is to discuss the RSK Improvement Proposals - RSKIPs, get the community involved, gather feedback, discuss the RSK consensus protocol, the formal process for proposing improvements, and the upcoming network upgrades. For more info, read the RSKIP Purpose and Guidelines.

https://youtu.be/lZ0Y4VHvR4Q

It was live-streamed on several platforms, thanks to everyone who joined the Livestream! For those of you who missed out on attending it live, visit the links below;

🎥 Watch the RSK Community Call August 2021 on Youtube (Replay).
🗣️ Propose your own RSKIPs
🔗 Join the RSK Research & Innovation Forum
🗣️ Suggest RSKIPs to discuss in the next community call
🔗Join our Open Slack Community and ask your questions in #research-and-innovation

The speakers on this call were:

John Light
Jose Dahlquist
Sergio Demian Lerner
Brendan Graetz

In this call, we discussed:

The Iris v3.0.0 Release

RSK is happy to announce that the RSK Iris 5th network upgrade was successfully activated at block #3,614,800 on 19th August 2021! Read about the benefits this milestone upgrade brings to the ecosystem in this article: Iris v3.0.0: What You Need To Know About RSK’s Upcoming Network Upgrade and also check out the previous community call which focused on RSKIPs that were included in Iris.

Expanding The Emergency Multisig (RSKIP-268)

John Light from Sovryn talked about modifying and expanding the Iris multisig from a 3-of-4 to a 7-of-12 multisig in line with the 7-of-12 PowHSM nodes required to operate the Powpeg Schnorr key aggregation to reduce the size of the emergency multisig transactions. He talked about enabling the current PowHSM nodes to be able to make taproot style transactions.

See related links:

Emergency Time Locks Refresh (RSKIP-207)

Jose Dahlquist talked about improving the time-locked emergency multisig of RSKIP-201. Prior to this time, the Powpeg unspent transaction outputs (UTXOs) are periodically spent in order to prevent the time-lock expiration, with the recent upgrade to the network, the new mechanism for the Bridge to command this time-lock refresh efficiently.

See related links:

Simplified Emergency Time-locks Refresh (RSKIP-264)

Jose also talked about simplifying RSKIP207 and prioritising UTXO consolidation. The aim of this RSKIP is the same as 207, but for 264 to be implementable, a consolidation of UTXOs should happen. If RSKIP-264 is activated, then the priority queue introduced in RSKIP-207 is not needed, and therefore RSKIP-264 should replace it.

See related links:

Bridge UTXOs Selection, Consolidation and Batching (RSKIP-265)

Sergio Demian Lerner talked about preventing the proliferation and fragmentation of UTXOs, consolidating the peg-ins into a small set when the number of UTXOs grows over a threshold concurrent with a method of peg-out output batching, this solves the problem of variable peg-out fees and reduces the effectiveness of some DoS attacks.

He highlighted the problems of the current UTXO management in RSK, these include;

UTXO denial of service, UTXO proliferation, UTXO fragmentation, UTXO uneven amount distribution, UTXO size shrink, peg-out cost, unfunded UTXO management, peg-out transactions fee bumping, etc.

Some problems addressed by RSKIP-265;

DOS attacks targeting the bridge
High peg out costs
UTXO proliferation and shrinkage
UTXO fragmentation, uneven amount distribution & UTXO refresh
Large variance in peg-out costs
Unfunded UTXO management

What RSKIP 265 does not solve;

Fee bumping

See related links:

User-triggered peg-out transaction fee-bumping (RSKIP-241)

Sergio talked about adding several methods to the bridge contract, allowing previously signed transactions to be rebuilt with higher Bitcoin transaction fees, and also allowing these transactions to be re-signed by the pegnatories.

See related links:

Decisions

Read about the decisions made during the call on the RSK Developers Portal

Summary

For more details on these, please watch the recording on Youtube.

Want to champion an RSKIP? Missed the previous RSK Community Call? Watch the recording on Youtube. Also, leave a comment on this thread for the next community call!

Thanks for reading!

Resources

RSK Community Call, July 2021 — Summary

Owanate Amachree — Sun, 25 Jul 2021 18:44:30 +0000

Introduction to Iris 3.0.0 network upgrades, powpeg security and flyover protocol.

On 16th July 2021, The RSK Ecosystem held its second community call. The aim of these community calls is to discuss the RSK Improvement Proposals — RSKIPs, get the community involved, gather feedback, discuss the RSK consensus protocol, the formal process for proposing improvements, and the upcoming network upgrades. For more info, read the RSKIP Purpose and Guidelines. It was live-streamed on several platforms, and we received quite a lot of questions and feedback from everyone who participated! For those of you who missed out on attending it live, we’ll catch you up in this article or read the detailed guide on What You Need To Know About RSK Upcoming Network Upgrade!

🎥 Watch the RSK Community Call July 2021 on Youtube (Replay).

🗣️ Propose your own RSKIPs

🔗 Join the RSK Research & Innovation Forum

🗣️ Suggest RSKIPs to discuss in the next community call

🔗Join our Open Slack Community and ask your questions in #research-and-innovation

The speakers on this call were:

Sergio Demian Lerner
Adrian Eidelman
Jose Dahlquist
John Light
… and hosted by Brendan Graetz

In this call, we discussed:

RSK Iris hard fork overview
RSKIP process
RSKIP-201, PowPeg Security
RSKIP-170, Pegin to any address
RSKIP-219, Pegin minimum reductions
RSKIP-176, Flyover

All about RSKIPs

The live event began with Adrian Eidelman talking about the Iris Hard Fork, which release has been talked about for months, and the new features and major improvements are ready to be made public.

Iris is a network upgrade or a hard fork — a hard fork is a set of changes to the underlying RSK protocol and those changes introduce new rules to improve the platform. These new rules are coded into the RSK reference client which is RSKj, and if the protocol rules change, all the nodes in the network need to be updated, otherwise those nodes not updated will remain on an old change with the previous rules.

Everyone running an RSK node instance (either a testnet or mainnet node) should ensure to update it before the IRIS updates are activated. No special consideration is needed, simply update your node instance, and it can be done in under a few minutes.

Scheduled Dates for IRIS Activation

The activation of the IRIS network upgrades will take place around Aug 19, 2021for Mainnet and Aug 4, 2021 for Testnet, the number of block activation numbers for mainnet is 3,614,800 and 2,060,500 for testnet respectively.

Components of Iris network upgrade

18 RSKIPs

There are 18 RSKIPs included in IRIS. All of these RSKIPs can be found in the meta RSKIP (RSKIP-187), which is an index of all the changes that are individually described in the RSKIPs repository.

Release

The tag name for this upcoming version upgrade is RSKj IRIS-3.0.0 which also contains both consensus and non-consensus improvements to RSKj. These include compatibility fixes at the JSON-RPC interface, performance enhancements of the node, et cetera. See the IRIS milestone on Github for a more detailed view of these changes.

The following are the included RSKIPs in RSKIP-187: Iris Network Upgrade.

RSKIP 153: Add BLAKE2 compression function F precompile
RSKIP 169: Rectify EXTCODEHASH implementation
RSKIP 170: 2WP peg-in transactions to any address
RSKIP 171: Arbitrary-length data return mechanism
RSKIP 174: Preserve balance in contract creation
RSKIP 176: Trustless fast BTC bridge
RSKIP 179: BTC-RSK timestamp linking
RSKIP 181: Add 2WP peg-in transactions reject events
RSKIP 185: Add 2WP peg-out transactions events and refund support
RSKIP 186: Preserve RSK PowPeg activation block height
RSKIP 191: Remove non-Ethereum opcodes from the virtual machine
RSKIP 197: Error Handling for Precompiled Contracts
RSKIP 199: Bridge performance improvement
RSKIP 200: ReceiveHeaders method limitations
RSKIP 201: Time-locked Emergency Multisignature
RSKIP 218: New fee rewards address for the RSK Core Developers Fund
RSKIP 219: Minimum peg-in and peg-out values reduced
RSKIP 220: Open Bitcoin blockchain oracle

IRIS Network Upgrade: Changes explained

RSKIP-170: Peg-in to a user-defined RSK address

The change in RSKIP-170 includes:

Allow users to peg-in BTC to any address in RSK, EOA or contract.
Output with an OP_RETURN op code and certain payload in the transaction
Backwards compatible
2WP wallets/tools can provide a much more friendly experience.

These are changes to the peg-in protocol, a very simple change but it enables a better peg-in experience, the goal of this consensus change is to basically allow users to specify any address in RSK (EOA or contracts) where the RBTC will be delivered when doing a peg-in transaction. This enables developers to build solutions that use this feature, for example, any wallet that provides this feature needs to implement this new feature, these changes are also backwards compatible, so node changes needed for the tools implementing this feature can keep working without issues. Some teams are already working on implementing this feature which can be seen in the image above.

RSKIP-219: Reduced minimum peg-in and peg-out values

The changes include;

Minimum required values for peg-in and peg-out have been halved.
Peg-in minimum: 0.01 → 0.005
Peg-out minimum: 0.008 → 0.004
Peg-out BTC fees must be less than 20% of the peg-out value.

RSKIP-176: Flyover Protocol

Jose Dahlquist explained the changes in RSKIP-176;

Converting BTC to RBTC in just a Bitcoin block is now possible
A new market opportunity for liquidity providers
Fully decentralized
Business rules are written in solidity
Bridge remarkable changes
Register Bridge UTXOs from a derived powpeg Federation address
Secured by the powpeg (HSM, ERP, etc)

The RSKIP Process

RSKIP-0

Sergio Lerner talked about the RSKIP-0, which is a document describing the RSKIP process, which will be discussed by the community before getting included in the RSKIPs. Essentially, how the RSK community initiates, discusses, and incorporates improvements. This process began in 2016, he said there are approximately 144 proposals published, and 20 proposals that have been abandoned or incomplete, he encouraged everyone who started a proposal to finish it, and that 40 proposals have been adopted and activated.

Sergio explained the process/workflow for submitting a proposal.

This starts with a draft which is a detailed document where you sketch your idea, the draft can be rejected if the community finds it of no value to the platform, or it contradicts some fundamental genesis of concepts of the platform. Or it can be activated — for e.g, if it is a change in consensus or if it is any other change that does not involve consensus, for e.g, a change in the interface of a node or CLI args or JSON-RPC then it is said to be adopted after several discussions have been had in the research forum, once accepted, it will be implemented in subsequent versions.

The below image shows the steps to follow, and how to get community feedback on your idea;

Do check out the RSKIP process. We encourage everyone from the RSK community to participate in this process, by creating new RSKIPs, discussing existing ones, and attending community calls like this one!

RSKIP-201: Powpeg Security

Time-locked Emergency Multisignature

A Timelock Emergency Multisig is a backup method to access the funds in the PowPeg that is only activated after one year of continued external attack.

DOS Attack against the RSK Mining Network (Very low risk)
DOS attack against the majority of the pegnatories (very low risk)
Seizure of the majority of the PowHSM devices (low risk)

Additionally, some internal bug or vulnerability bricks the PowHSM.

Sergio also talked about the new bitcoin script for Powpeg address, which has two execution paths — the normal peg out script path and the emergency peg out script path, see image below;

The reason for a one-year time lock and what signatories will do in the case of an emergency. He also gave a brief history of the PwoPeg since 2020, the private key holders, the future of the emergency multisignature and the original security concerns that motivated an emergency multisig which were;

Firmware bugs
Flash Memory Failure
Board Failure
Censorship, Seizure and Ransom Demands.

For more info on RSKIP-201, read The RSK Emergency Multisig article by Sergio Lerner.

John Light from Sovryn expressed concerns about the potential degradation of the security of the PowPeg which could arise as a result of adding the emergency multisig, he suggested some improvements like expanding the number of signatories on the multisig, securing the private keys using PowHSM devices. Sergio responded to this by saying that future network upgrades will prioritise security. Adrian added to this by saying that discussions are already underway and that the next upgrade will see improvements like the one mentioned by John Light.

Q & A

For more details on these, please watch the live recording on Youtube.

Want to champion an RSKIP? Missed the first RSK Community Call? Watch the recording on Youtube. Also, leave a comment on this thread for the next community call!

The following questions were asked during the community call;

Why is an Emergency and a Hard Fork?

Answer: Adrian responded by saying that though the term used calls for valid concerns, he said that there’s nothing to worry about especially with regards to their RBTC and that this is a planned hard fork and a consensus change to improve the features of the network.

Does the user need to do anything? Will we end up with RBTC and the “old” hard forked RBTC as it happened with BTC’s hardfork?

Answer: Brendan responded by saying no, you generally don’t need to do anything unless you’re running an RSK node. If you are running an RSK node, do update it to the latest version of RSKj as soon as possible.

Resources

What do you want to discuss in our next community call?

The next RSK Community Call will happen on August 5th 2021 with discussions including the next hard fork.

Thanks for reading!

The difference between a Cryptocurrency and a Token

Owanate Amachree — Tue, 25 May 2021 13:50:46 +0000

What is a Digital Asset?

In broad terms, a digital asset is a non-tangible asset that is created, traded, and stored in a digital format. Using this definition In the context of blockchains, digital assets include cryptocurrency and crypto tokens.

The blockchain terms; token and cryptocurrency are often used interchangeably, as these are both digital assets on blockchains. The biggest difference between a cryptocurrency and a token is that cryptocurrencies are the native asset of a

blockchain like BTC, RBTC, or ETH, whereas tokens are built on an existing blockchain, using smart contracts. Most commonly, these are EIP-20 tokens.

The following chart summarises the similarities between the two:

As we can see, these are largely the same from the perspective of the end user. However, there are large technical differences between the two. Let’s dive a little bit deeper into the technical differences:

Blockchain, Blocks, Transactions, and Signatures

Here’s a whirlwind introduction to blockchain:

End users use public key cryptography to digitally sign information
This signed information is a transaction
The transaction is broadcast to a peer-to-peer network of computers running the blockchain node software
All the nodes have to reach a consensus on whether or not the transaction is valid
If the transaction is valid, it gets added to a block, which is a set of transactions
Many computers on the network build these blocks of transactions, but only one block gets added at a time
These blocks form a single chain, called a blockchain

Note that many details have been left out of the above description, for the sake of brevity.

Public key cryptography is used in blockchain networks, mainly for digitally signing information, and then subsequently verifying those signatures. This was the process of transaction creation and transaction verification. The user possesses both a private key and a public key, and needs to keep the private key a secret, while allowing the public key to be broadcast widely.

Transfer Transactions vs Smart Contract Interaction Transactions

In Bitcoin, and in many other blockchains, the information being signed was about one account transferring units from itself to another account. These units are encoded into the software protocols of the blockchain software itself, and are known as cryptocurrency. In this system there is only one type of transaction.

In Ethereum, RSK, and many other blockchains that support smart contracts, the information being signed was about one account transferring units of cryptocurrency from itself to another account too. However, they added a new concept where you could have “smart contracts” which are autonomously executing code and data stored on the blockchain. These smart contracts may be thought of as a special type of account. Now an account could sign information that does not transfer any units of cryptocurrency, but instead contains instructions for a smart contract to execute some code or store some data. In this system, there are two types of transaction. Read more about Smart contracts in How to Build a Full Stack dApp on RSK.

Tokens

Tokens behave very similarly to cryptocurrencies, in the sense that they are a type of currency that exist on a blockchain, and can be transferred from one account to another. However, unlike cryptocurrencies, their behaviour is not built into the blockchain software itself. Instead their behaviour comes about by implementations in smart contracts. These smart contracts tally the units of the token transferred between accounts.

To transfer units of these tokens, an account signs a transaction telling the smart contract to debit a number of units of the token from its tally, and credit the same number of units of the token to the other account’s tally. Most tokens conform to the EIP-20 token standard, and in fact the majority of all smart contracts on blockchain networks tend to be of this type; making it easy for users, wallets, exchanges, etc to interact with them.

When interacting with blockchain networks, it is important to be aware of this distinction. On Ethereum, Ether is the cryptocurrency, and other “currencies” are tokens. Likewise, on RSK, RBTC is the cryptocurrency, and other “currencies” are tokens. Some practical reasons to take note of this are that:

Fees (or gas) for transactions are cheaper when transferring the cryptocurrency, and more expensive when transferring tokens.
Fees (or gas) is always paid for in the cryptocurrency, and therefore when transferring tokens, you will still need some cryptocurrency in the same account.

NOTE: When talking about tokens, you will see the terms ERC-20 as well as EIP-20. These are both the same. At the outset, the process for defining standards for Ethereum, and Ethereum-compatible networks, was called “Ethereum Request for Comment”. This process has since been refined and renamed to “Ethereum Improvement Proposal”.

Visit the RSK Developer's Portal for more info or join the Slack Community!

Thanks for reading!

Originally published at the RSK Developer's Portal

DEV Community: Owanate Amachree

Try it yourself! - Dogfood Your Web3 Ecosystem

OBJECTIVE #1

OBJECTIVE #2

OBJECTIVE #3

OBJECTIVE #4

OBJECTIVE #5

OBJECTIVE #6

OBJECTIVE #7

OBJECTIVE #8

OBJECTIVE #9

OBJECTIVE #10

Next

RBTC vs. WRBTC: What are Wrapped Cryptocurrencies?

What is a Wrapped Token?

How do they work?

Difference between BTC, RBTC, WRBTC, and WBTC

Why use WRBTC?

Other Benefits of using wrapped tokens?

Where to Get Wrapped RBTC (WRBTC)?

RBTC and WRBTC

BTC and RBTC

How to set up a Hardhat project for RSK Testnet

Prerequisites

What is Hardhat?

1. Setting up your node.js environment

1.1. Installing Node.js

2. Creating and configuring a new Hardhat project

2.1. Configure hardhat.config.js to connect to RSK Testnet

2.2. Network configuration

2.3. Hardhat Network

2.4. JSON-RPC based networks

2.5. HD Wallet Configuration

2.6. Solidity configuration

2.7. Path configuration

2.8. Mocha configuration:

The updated hardhat.config.js file:

3. Let's take a look at the concepts of hardhat tasks and plugins.

3.1. Tasks

3.2. Plugins

4. Writing and compiling smart contracts

4.1 Creating the smart contracts

4.2. Code walkthrough

4.3. Address data type

4.5. Implementing the smart contract functions

Implementing the constructor

4.6. Transfer Function

4.7. Implementing the balanceOf Function

The updated Smart Contract

4.8. Compiling contracts

Testing the smart contract

How to verify a smart contract on the RSK Block Explorer

Getting started

Verifying the smart contract

The A-Z of Stablecoins

What are Stablecoins?

Importance of Stablecoins

Types Of Stablecoins

Bitcoin-backed Stablecoins

DOC

Features

Benefits

Where to Get DOC Tokens?

RDOC

How to Get RDOC?

XUSD

Why Use XUSD?

RBRZ Tokens

Features

Why Use BRZ?

How to Get RBRZ?

Ethereum-based Stablecoins

rUSDT

How to Get rUSDT?

rDAI

Why use rDAI?

How to Get rDAI?

Resources

RSK Community Call, December 2021 - Summary

The RSKj IRIS v3.2.0

2.1. Configure `hardhat.config.js` to connect to RSK Testnet

The updated `hardhat.config.js` file: