Loading...

Follow mycryptopedia on Feedspot

Continue with Google
Continue with Facebook
or

Valid

Dharma Protocol is a decentralized finance application operating on the Ethereum blockchain; it allows for the creation and trading of digital lending products by tokenizing debt. It is part of a new wave of decentralized finance products that seek to democratize access to financial services.

The key players within the Dharma ecosystem include: debtors (borrowers), creditors (lenders), underwrites and relayers. Debtors, individuals who would like to receive a loan, can approach creditors and receive one in exchange for paying back the initial amount plus interest. Underwriters on the Dharma platform help debtors structure their loans by providing key pieces of information such as: risk level, negotiating terms and the interest rate. Lastly, relayers help in finding creditors to fund loan applications by hosting it on their global order book.

How Does Dharma Protocol Work?

At a fundamental level, Dharma operates on-top of various smart contracts known as the Dharma Settlement Contracts. Each play a different role in the operation of the platform and is crucial to its functionality. One of those key contracts is the Terms Contracts.

The Terms Contracts is used to define the terms in a debt agreement between two individuals. For example, if Bob agrees to receive a loan from Alice at 5% interest to be paid monthly, then the terms of that agreement is codified in a Terms Contract. This provides the benefit of allowing any potential future disputes to be more easily resolved, as proof of the agreement between both parties is recorded on an immutable ledger.

When a creditor and a debtor enter into a debt agreement, a signed cryptographic message called a Debt Order is then submitted. If the Debt Order is valid, then the loan amount is transferred from the creditor to the debtor, at which point a unique token known as a Debt Token is minted to the creditor. Ownership of a Debt Token entitles the owner to all the repayments of the loan from which the token was minted from. Debt Tokens are tradable and thus can be exchanged between individuals in an open market place.

Defaults, Collateralized & Uncollateralized Loans

Defaults occur when a borrow is unable to make their loan repayments to a creditor as agreed to by their Terms Contract. On the Dharma Protocol, a loan is considered to have entered into default when the expected amount repaid exceeds the actual amount repaid at any point in time.

Collateralized loans are a mechanism by which creditors can recoup somewhat the value of their loan if the borrower was ever to default. To illustrate, consider that Alice and Bob enter into a debt agreement in which she lends Bob 5 ETH. Bob agrees to put up 2 ETH as collateral such that if he was ever to default on the loan, the 2 ETH would then be transferred to Alice. Collateralizing a loan reduces the risk to the creditor as it guarantees that they will recoup some of the value of their loan upon a debtor’s default.

This is in contrast to Uncollateralized Loans in which no asset has been put up by the borrower upon entering a loan agreement. Uncollateralized Loans are considered more risky than their counterpart, collateralized loans, as the creditor has no way of recouping any value of their loan amount if the borrower were ever to default. However, the Dharma Protocol utilizes a key player in its ecosystem known as an Underwriter, that makes it less risky for creditors to enter into uncollateralized loan agreements.

Underwriters

Underwriters are trusted third-parties that help facilitate loan agreements between borrowers and lenders by making a prediction as to how likely it is that a borrower will be able to successfully make their loan repayments. Underwriters receive a fee for providing such a service. Dharma Protocol implements a reputation system wherein each Underwriter is assigned a rating depending on the previous accuracy of their predictions. This incentivizes Underwrites to make accurate predictions so as to maintain a good reputation and therefore increase their ability to earn more fees. Predictions made by Underwriters are permanently recorded on the blockchain and is then associated with their public key, allowing anyone to see the accuracy of their previous predictions.

Debt Orders & Relayers

A Debt Order on the Dharma protocol is a representation of an individual’s intent to borrow a certain amount. A Debt Order is said to be filled when a creditor agrees to the terms outlined in the Debt Order by the borrower. A Debt Order is considered filled when it has been signed by both the borrower and lender. The signature of an Underwriter will also be required if one was involved in facilitating the loan.

Relayers are another key player in the Dharma Protocol ecosystem because they help borrowers find creditors to fill their loans by hosting their Debt Order in an open order book. Relayers then receive a fee for every loan that is successfully matched to a creditor. One example of a relayer currently operating on Dharma Protocol is Bloqboard.

Conclusion

To conclude, Dharma protocol is an open financial protocol that aims to democratize access to lending products through its decentralized lending platform. According to DeFi Pulse, an analytics platform for decentralized finance applications, a total of $13 million dollars have been locked up in the protocol. This serves as an indication as to the value that has been transacted over the platform.

Through its ecosystem of lenders, borrowers, underwriters and relayers, it aims to provide a viable alternative to today’s modern financial system. Virtually any type of loan can be created on the Dharma Protocol; from regular consumer loans to corporate bonds.

However, Dharma Protocol is not the only decentralized finance project operating in the lending space. There includes other such as: Compound Finance and Ethlend.

The post What is Dharma Protocol? A Complete Beginner’s Guide appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
What is Ethereum Truffle? A Detailed Guide

Smart contracts for Ethereum are usually developed using the Solidity programming language. All that is required for such a development task is a text editor and a Solidity compiler. However, smart contracts are different from other programs, in that they are meant to be deployed on blockchains. Testing smart contracts efficiently and deploying them onto an Ethereum network can be surprisingly difficult without additional tool support. The Ethereum Truffle framework is designed to make the testing of smart contracts, and the deployment of smart contracts onto an Ethereum network, a much simpler process. 

Although simple contracts can be tested and deployed using a browser-based development environment such as Remix, this becomes cumbersome for larger projects that may consist of multiple contracts and have dependencies on external libraries.

In such a scenario, it is best to use a development framework that integrates code compilation, testing, and deployment, and also allows workflows to be automated.

Ethereum Truffle Framework

The Truffle Suite consists of three components that together provide such a development framework:

  • The Ethereum Truffle Framework is the actual development toolchain, integrating compilation, testing and deployment.
  • Ganache is a locally deployed blockchain simulator with a graphical user interface that can be used to simulate blockchain networks and live-test contracts without having to set up real test networks or having to deploy to a remote network.   
  • Drizzle is a collection of frontend libraries aimed at providing components for building web applications that can connect to the smart contracts developed.

In this article, we will focus on the former two components, as these are typically used together to develop smart contracts for the Ethereum blockchain.

Ethereum Truffle is based on JavaScript, in that configuration, deployment scripts, and tests are written in JavaScript. Although, tests can also be written directly in Solidity.

Installation and Getting Started

It is very easy to install the Ethereum Truffle framework. As with most JavaScript-based tools, the npm package manager is used:

  • npm install -g truffle

Once the framework is installed, it also makes sense to download and install the Ganache blockchain simulator. As this is an application with a graphical user interface, the official Ganache website provides installers for most popular platforms.

Once Truffle has been installed, a project can be initialized in two ways. A bare project can be created by typing:

  • truffle init

Alternatively, the truffle unbox command can be used to create a project with some existing code. For example, a very simple token can be created with:

  • truffle unbox metacoin

The above creates the project from a so-called Truffle box. These contain boilerplate code and configurations upon which projects can build to get started quickly. A number of these Truffle boxes can be found on the official website.

Many programmers will use Truffle in combination with additional npm-installed libraries, for example, Open Zeppelin’s comprehensive smart contracts library. In this case, the required dependencies file, package.json, can be created at this point with:

  • npm init

Of course, this optional step can be left out or substituted with the equivalent command for other package managers that may be used to handle dependencies.

Development and Deployment

Using the above-mentioned metacoin boilerplate, created with truffle unbox metacoin, results in the following directory structure:

├── LICENSE
├── contracts
│   ├── ConvertLib.sol
│   ├── MetaCoin.sol
│   └── Migrations.sol
├── migrations
│   ├── 1_initial_migration.js
│   └── 2_deploy_contracts.js
├── test
│   ├── TestMetacoin.sol
│   └── metacoin.js
└── truffle-config.js

The contracts directory is where developers should place their solidity source files. The Migrations.sol file is a contract created by Ethereum Truffle and is used as part of the deployment process. In most cases, this file can be left untouched.

The migrations directory holds files developers can use to configure which contracts should be deployed. We will get to this later.

The test directory should hold JavaScript and Solidity test files. Again, the Metacoin boilerplate includes examples for this.

The truffle-config.js is a configuration file used to define how Truffle can connect to different Ethereum networks, and to specify details, such as the compiler version to be used.

This very simple configuration is sufficient to connect to Ganache running on the local host:

module.exports = {

 networks: {

   test: {

     host: “127.0.0.1”,

     port: 7545,

     network_id: “*”

   }

 }

};

Note that Ganache typically uses port 7545 to expose the Ethereum JSON-RPC interface. It is fairly obvious from the file format how a connection to a different network could be set up, for example, through a local Ethereum node on a different port.

Once contracts have been written they can be compiled using the command:

  • truffle compile

Adding the –all flag forces a rebuild of all contracts.

Compiled contracts end up in a build directory.

In order for a contract to be deployed, the deployment rules need to be specified in the numbered files in the migrations directory. These are executed in ascending order, according to the number the file name begins with.

Let’s look at the 2_deploy_contracts.js file in the Metacoin example:

const ConvertLib = artifacts.require(“ConvertLib”);
const MetaCoin = artifacts.require(“MetaCoin”);

module.exports = function(deployer) {
deployer.deploy(ConvertLib);
deployer.link(ConvertLib, MetaCoin);
deployer.deploy(MetaCoin);
};

The code deploys two contracts, a library contract and a consuming contract, and links them. Linking in this context means that the MetaCoin contract consumes the ConvertLib library, for which it needs to know its address after deployment. Truffle deals with this complexity internally.

As already explained, Ganache is a local test and simulation environment, on which contracts can be deployed. Once started, the following user interface is visible:

As can be seen, a number of accounts are automatically created for testing.

With Ganche running and the example configuration shown above, the Metacoin contracts can be deployed using the following command:

  • truffle migrate

It is sometimes necessary to force re-deployment with the –reset flag. The deployment transactions should be visible in the Ganache user interface instantly.

Testing

Testing smart contracts is where the advantages of Ethereum Truffle really become apparent.

One way of simply interacting with a contract deployed on Ganache (or other networks) is to use Truffle’s JavaScript console. This console provides Ethereum’s web3.js interface and also Truffle’s own abstraction, truffle-contract.  

This allows simple contract interactions such as the following example sequence (based again on Metacoin):

truffle(ganache)> let instance = await MetaCoin.deployed()
undefined
truffle(ganache)> let balance = await instance.getBalance(accounts[0])
undefined
truffle(ganache)> balance.toNumber()
10000

Note that the above capture includes the command prompt and the replies.

More advanced tests can be defined in the test directory in JavaScript or Solidity and executed with the command:

  • truffle test

JavaScript-based testing is arguably more powerful in some situations. Truffle uses the popular Mocha JavaScript testing framework in combination with the Chai assertion library. Explaining the syntax is beyond the scope of this article, but looking at the Metacoin example tests should give an idea of how powerful the framework can be for automated testing.

Conclusion

Of course, we have only scratched the surface on Truffle’s possibilities in this article. Configurations can be adapted to allow for deployments onto different networks for production and testing, using different compilers and optimization parameters.

It is also possible to integrate external tools, such as static code analyzers into the automated workflow.

Further details on these advanced cases can be found in the official Truffle documentation.

The post What is Ethereum Truffle? A Detailed Guide appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
What is Web3.js? A Detailed Guide

Digital assets such as cryptocurrencies (or programmable tokens) and smart contracts are a central component of decentralized applications (DApps), in that they are deployed on the blockchain. However, to interact with these on-chain components, transactions need to be created on the blockchain. For a user or off-chain software to create a transaction on the blockchain, a node needs to relay the transaction to the underlying peer-to-peer (P2P) network. Web3.js is a collection of libraries that allows programmers to interact with these on-chain components, by being able to facilitate a connection to Ethereum nodes.

In Ethereum, nodes provide low-level interfaces for users to submit transactions. Transactions can be received by a node through a JSON RPC interface. JSON RPC is a textual encoding format allowing running processes to receive data. Nodes participating in the Ethereum network may choose to expose this interface in different ways, depending on its configuration and the underlying software implementation. Common options include HTTP connections, IPC or WebSockets. For example, the Go Ethereum implementation (geth) can be configured to expose the RPC interface via HTTP with the command line option “geth –rpc”.

Nodes can accept transactions that have already been signed with a valid private key belonging to an Ethereum address, or they may be asked to sign the transaction with a key hosted within the node. Transactions are translated by the node to a sequence of bytes encoded in the Ethereum internal format. Different fields in this sequence have different meanings, such as representing smart contract addresses and methods that are to be invoked. Once a valid transaction has been encoded correctly, it is submitted to the network.

The JSON RPC interface does not only deal with transactions, but also with other interactions such as obtaining information on the network state.

Users or applications may submit JSON RPC invocations directly to a node, forming the JSON data-structure required and submitting it to the exposed interface. However, this is cumbersome and usually additional layers of software are used to provide higher-level abstractions. To this end, programmers usually rely on language bindings encapsulated in libraries for different programming languages. This enables programmers to work in their application’s language and create blockchain interactions, such as sending a transaction. This is then automatically translated into the JSON RPC format and submitted to an Ethereum node.

The Web3.js Library

Web3.js is a popular library that allows programmers to interact with the Ethereum blockchain. It represents a JavaScript language binding for Ethereum’s JSON RPC interface, which makes it directly usable in web technology, as JavaScript is natively supported in almost all web browsers. Web3.js is also commonly used on the server side in Node.js applications and in Electron-based desktop applications.

Web3.js can be used to connect to the Ethereum network via any Ethereum node that allows access via HTTP. This may be a local node, a node hosted by the DApp provider, or public gateways such as Infura, which operate free Ethereum access points.

One common way of integrating a web browser application with Ethereum is to use the Metamask browser extension in combination with Web3.js. Metamask is an in-browser Ethereum wallet that injects a Web3 provider object into the browser. A Web3 provider is a data-structure providing a link to publicly accessible Ethereum nodes. Using Metamask allows users to manage private keys and sign transactions within their web browser. Using Metamask in combination with Web3.js, in a web interface, provides a convenient way to interact with the Ethereum network.

Getting Started

There are currently two versions of Web3.js available. The current stable version (0.3) has been all but replaced by version 1.0. However, version 1.0 is officially still in the beta stage. Nevertheless, it is the version currently used by most developers and the examples in this article are based on version 1.0.

In order to use Web3.js in a project, you must first obtain a copy of the library. There are a number of ways to achieve this. One of the most common is to use the NPM package manager, which should be familiar to most JavaScript programmers:

  • npm install web3

Another way is to download the source code from the project’s Github repository. To include Web3.js in a web page, a file Web3.js must be included in the HTML code.

In the case of a Node.js application, the library can be included with:

  • const Web3 = require(‘web3’);

In order to use Web3.js to connect to Ethereum, a programmer must specify a Web3 provider. The code for this depends, of course, on the particular node to which the programmer wishes to connect. The following is an example that might be used in a web application to connect via the Metamask browser extension already mentioned above:

  • const web3 = new Web3(Web3.givenProvider, null, {});

Metamask injects a Web3 provider into the browser. The above code obtains a reference to this provider and initializes Web3.js to use it.

To interact with a deployed smart contract, the contract’s address and the Application Binary Interface (ABI) is required. The ABI is a description of the contracts public interface in the form of a JSON object. For example, the ABI corresponding to an ERC-20 token can be found at https://github.com/ethereum/wiki/wiki/Contract-ERC20-ABI.

Assuming the ABI description is stored in a variable “abi” and the contract address in a variable address, the contract can be referenced in a contract object with the following code:

  • let contract = new web3.eth.Contract(abi, address);

This object can now be used for sending transactions to the contract, for example:

  • contract.methods.transfer(toAddress, value).send({from: myAddress});

In the above code, the variable “toAddress” is assumed to hold the receiver’s Ethereum address, and “myAddress” is assumed to hold the origin address. This simple transaction is to be signed automatically by the specific Web3 provider used. This means that the provider needs to have control over the private key belonging to the account “myAddress”.

Web3.js Advanced Usage

The above code examples have been simplified in order to explain the basic flow of Web3.js. Real world examples are often more complicated. For example, it is usually necessary to check whether a transaction has been confirmed or not. As this may take a long time, Web3.js is asynchronous, in that calls return immediately, before the result is available. This means that programmers need to deal with callback functions that can be registered to be executed on certain events, for example, on the availability of a transaction hash.

Furthermore, there may be cases in which the Web3 provider does not have access to the private key required to sign a transaction. In this case, it is possible to send so-called raw transactions that are already well-formed and signed by the corresponding private key.

Further details on these advanced cases can be found in the official web3.js documentation.

The post What is Web3.js? A Detailed Guide appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
What is Wrapped Bitcoin (WBTC)? A Detailed Guide

Wrapped Bitcoin (WBTC) is an ERC20 token that is designed to act as a 1:1 representation of Bitcoin on the Ethereum blockchain. Wrapped Bitcoin is intended to capture the benefits that can result from the tokenization of the Bitcoin cryptocurrency, such as integrating Bitcoin’s liquidity with Ethereum-based decentralized applications (dapps) and decentralized exchanges. Wrapped Bitcoin can also be considered as being a DeFi (decentralized finance) project, because capturing Bitcoin’s liquidity on the Ethereum blockchain could facilitate the wider adoption of Ethereum-based DeFi applications that operate in areas such as: lending, decentralized exchanges, payments and more.

Asset tokenization can produce a number of advantages, such as:

  • Increased transaction speeds – assets that are tokenized can benefit from fast transaction execution. For example, a transaction that is executed with Wrapped Bitcoin, that utilizes the Ethereum blockchain as the transfer medium, would execute faster on the Ethereum blockchain than the Bitcoin blockchain.
  • Usability – Wrapped Bitcoin is a token that satisfies the ERC20 technical standard, a standard that has seen its adoption by numerous exchanges, dapps and wallet providers in the ecosystem. This provides added usability to Wrapped Bitcoin, as it too can enjoy the products and services that support the ERC20 technical standard.
  • Greater liquidity – the digital asset of choice when it comes to trading ERC20 tokens, or interacting with dapps, is Ethereum. However, Bitcoin possesses significantly more liquidity than Ethereum, thus, introducing a tokenized Bitcoin to the Ethereum blockchain, such as Wrapped Bitcoin, serves as an opportunity to introduce greater liquidity when trading ERC20 tokens or interacting with dapps.
Wrapped Bitcoin (WBTC) Model

With Wrapped Bitcoin, one unit of WBTC is backed by an equivalent unit of one Bitcoin. The process of backing a digital asset can be achieved in a number of ways, for example: algorithmically or in a centralized fashion.

  • Algorithmic – with this method, smart contracts are used to control the supply and demand of the token, so that its price can be kept in line with the asset that is backing the digital token.
  • Centralized – with the centralized model, the asset backing the token is stored with a centralized organization. The organization will mint or distribute tokens that equal the number of assets that are backing the token, with the organization also publishing proof of reserves to show that the organization does in fact hold the equivalent number of assets backing the minted tokens in circulation. Examples of this model include: Tether and USD Coin (USDC).

Wrapped Bitcoin has adopted a variant of the centralized model. Instead of relying on one entity to take on the responsibility of maintaining assets and underlying tokens, with the Wrapped Bitcoin model, maintenance is carried out by a consortium of entities that each perform different roles on the network.

Network Roles

The roles that this consortium of entities must play on the network can be subdivided into the following:

  • Custodian – this is the entity or party that will hold assets (both WBTC and BTC). The custodian will be responsible for exchanging wrapped bitcoins for bitcoins, via a minting process, and also redeeming bitcoins in exchange for deposited wrapped bitcoins, done through a burning process. The role of the custodian will be played by BitGo, a custody solutions provider for digital assets.
  • Merchant – merchants are the parties to which wrapped tokens will be minted to, and burnt from. Thus, merchants play a significant role in the distribution of Wrapped Bitcoin tokens. Each merchant holds a key that allows them to initiate the minting and burning of Wrapped Bitcoin tokens. Token exchange protocols, Kyber and the Republic Protocol, will play the role of merchants on the network.
  • WBTC DAO Member – the addition and removal of custodians and merchants on the network will be controlled by a multi-signature contract. Key holders to this contract will be held by entities on the network to form the WBTC DAO.

Participating custodians of Wrapped Bitcoin are expected to have a pooled wallet to support merchants. The wallet will be used to send funds to on-chain merchant addresses that are whitelisted. The wallet will also be configured with a multisignature set-up, with the keys to the wallet being controlled by the custodian.

Users of Wrapped Bitcoin can acquire more of the token through the merchants on the network. Individuals can use Wrapped Bitcoin like any other ERC20 token in the Ethereum ecosystem.

Minting Wrapped Bitcoin (WBTC) Tokens

Minting is the process by which new Wrapped Bitcoin tokens are created. Minting of Wrapped Bitcoin tokens are executed by a custodian, but the process of minting must be initiated by a merchant. Minting is a process that occurs strictly between the custodian and merchant, the user is not involved in this process.

The minting process is as follows:

Steps for minting WBTC
  • The merchant initiates a transaction that authorizes the custodian to mint and deliver X WBTC to the merchant’s whitelisted address on the Ethereum blockchain.
  • The merchant will then send the custodian X BTC. The number of bitcoins sent to the custodian will equal the amount of WBTC that is sent to the merchant’s address.
  • The custodian will wait for 6 confirmations of the BTC transaction, which signals that the transaction is effectively irreversible.
  • The custodian will then create a transaction to mint X new WBTC tokens to the merchant’s address.

Steps for Users to Exchange BTC for WBTC

As mentioned earlier, users are not involved in the minting process, thus, they must acquire WBTC tokens through a merchant:

  • User requests WBTC from a merchant.
  • The merchant will carry out KYC and AML procedures in order to verify the identity of the user.
  • The user and merchant will then perform an atomic swap, in which the user receives WBTC in exchange for their BTC. Users can also use an exchange that they trust to exchange their BTC for WBTC.

Burning Wrapped Bitcoin (WBTC) Tokens

Burning refers to the process in which WBTC tokens are burned and redeemed for BTC. Only merchants are able to burn wrapped bitcoin tokens, and the steps for the burning process are as follows:

  • The merchant will initiate a burn transaction on the Ethereum blockchain, burning X WBTC tokens.
  • The custodian will then wait for 25 block confirmations for this burn transaction, to signal that the transaction is effectively irreversible.
  • The custodian will then release X BTC to the merchants Bitcoin address.
  • The custodian then makes an Ethereum transaction to mark that the burn request has been completed.

Steps for Users to Exchange WBTC for BTC

In order for a user to exchange their WBTC for BTC, they can do so via a merchant on the network:

  • User will firstly request the redemption of tokens from a merchant.
  • The merchant will carry out KYC and AML checks to verify the identity of the user.
  • The user and the merchant will then engage in an atomic swap, where the user will receive bitcoins in exchange for their WBTC tokens. The user can also choose to execute the transfer of WBTC for BTC on an exchange that they trust.

Wrapped Bitcoin (WBTC) and Sidechains

In the initial phases, the Wrapped Bitcoin token will be launched on the Ethereum blockchain. However, the Wrapped Bitcoin team recognizes that the increased adoption of Ethereum could see the cost of executing transactions and creating dapps on Ethereum rise to a point where it becomes too expensive to carry out these activities. Thus, if this scenario arises, then there is the possibility of introducing a pegged sidechain to deal with any increase in transactional throughput.

Existing software that allows for pegged sidechains, such as parity-bridge, can be run by DAO members. It is planned that this sidechain will operate on its own proof of authority network, using the Aura consensus algorithm. Benefits that can be captured from leveraging sidechain technology include:

  • Increased throughput, which allows for more scaling.
  • Minimal transaction cost (transaction cost will exist to prevent spam transactions).
  • Easy to support with existing clients and wallets.

It is planned that Wrapped Bitcoin will be the first asset to be deployed on any future sidechain, and alongside this sidechain, will be a suite of components to foster the creation of an ecosystem. These components include:

  • Node Software and Configuration
  • Block Explorer
  • Wallet Providers
  • Block Validators
  • Multi-sig Authorities
Governance

The governance model adopted by Wrapped Bitcoin is that of a DAO (Decentralized Autonomous Organization). The token contract that pertains to Wrapped Bitcoin is governed by a multisignature contract in which signatures are required from DAO members in order to add or remove entities. All custodians and merchants are able to become DAO members, however, entities that are not custodians or merchants can still become a DAO member.

With the multisignature contract set-up, an M of N signature will be used, where M is the required number of signatures and N is the total number of DAO members. The values that are to be attached to M and N is decided between DAO members.

Trust Model

The Wrapped Bitcoin model arguably does require trust to be placed in participating entities. For example, custodians are trusted not to steal stored assets. The wrapped token model attempts to minimize this trust in a few different ways:

  • Custodians are not able to mint their own tokens. The process of minting can only occur if it is initiated by a merchant. Thus, control of token creation is shared between the custodian and the merchant.
  • Quarterly audits by independent third parties are promised to be conducted in order to verify that all Wrapped Bitcoin tokens that are minted have an equivalent number of bitcoins that are stored in custodian wallets.
Fees

The fee model of Wrapped Bitcoin is such that the transfers of WBTC between users will have no cost apart from network fees. This network fee can be further subdivided into the following three categories:

  • Custodian fees – this fee will be taken by the custodian when a merchant initiates a minting or burning of Wrapped Bitcoin tokens.
  • Merchant fees – this fee is taken by the merchant when the user seeks to exchange bitcoins for Wrapped Bitcoin tokens, or when they want to exchange their Wrapped Bitcoin tokens for bitcoins.
  • Sidechain transaction fees – this fee is primarily intended to prevent spam transactions on the sidechain network. Sidechain transaction fees will be equally shared amongst all entities that are running nodes on the sidechain.
Transparency

The Wrapped Bitcoin model will also be accompanied by high levels of transparency. Details that will be made transparent will be reflected in the dashboard. Details that will be made transparent include:

  • Names and details of entities that are performing different roles on the network.
  • Status of mint and burn orders (e.g. pending, processing, cancelled, complete).
  • The total of bitcoins that are stored by custodians on the network.
  • Total amount of Wrapped Bitcoin tokens in the network. This figure should be the same as the number of bitcoins stored by custodians or slightly lower.
  • Quarterly audits in the form of transactions which prove that the custodian has the keys to the stored bitcoins.
  • Merchant and custodian Ethereum addresses.
  • The bitcoin address that will be associated with each merchant, and also the bitcoin address controlled by the custodians.
  • Links to the open source token contract code and deployed contract on a block explorer.

The post What is Wrapped Bitcoin (WBTC)? A Detailed Guide appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Top 5 DeFi (Decentralized Finance) Projects

Decentralized Finance (DeFi) refers to open-source software applications on the Ethereum blockchain (also known as decentralized applications, or DApps) that serve as financial instruments or protocols, primarily involving cryptocurrencies. The goal of DeFi is to cultivate trustless and democratic financial blockchain activity, while preventing censorship and rent-seeking activity. Here is a breakdown of five leading top DeFi projects and the specific problems that they aim to solve.

1. MakerDAO

Currently headquartered in Santa Cruz, California, Maker is a decentralized autonomous organization (DAO) that focuses on volatility mitigation through its Dai stablecoin. Its CEO is Rune Christensen, who studied at Copenhagen Business School prior to founding the organization, and its CTO is Andy Milenius, a former software engineer at Amazon.

The Dai stablecoin, which is pegged to the US dollar, can be collateralized by a separate security token (a process known as a collateralized debt position, or CDP). Through this and other methods, Maker’s primary objective is to establish a stable exchange of value on the Ethereum blockchain.

2. Uniswap

Uniswap is a token exchange protocol that is based on the ERC20 token standard (which is widely utilized for its ability to establish commonality between different tokenized assets). It was created by Hayden Adams, who first became interested in smart contract development when a friend of his at the Ethereum Foundation convinced him to learn Solidity.

Uniswap serves as an interface through which users can exchange ERC20 tokens. It emphasizes ease-of-use and transparency, and also facilitates precisely one exchange contract per ERC20 token.

3. Compound Finance

Initially funded by Coinbase and Andreeseen Horowitz, Compound Finance is a protocol for Ethereum-based money markets. It was created by Robert Leshner and Geoffrey Hayes, who had previously started two other companies together, in addition to having worked various technology and finance jobs.

Compound enables cryptocurrency holders (informally known as ‘hodlers’) to lend out their unused assets at algorithmically calculated interest rates. Although those rates are subject to market fluctuations, the company anticipates them to stay generally within the 5% to 10% range. Beyond the immediate benefits of lending and borrowing opportunities that this service creates, it could also potentially add a lot of liquidity to cryptocurrency in general if it succeeds.

4. Dharma Protocol

Built on top of the 0x protocol (which is a modular system for decentralized exchange on the Ethereum blockchain), Dharma enables permissionless management of debt instruments through smart contracts and other Ethereum-based mechanisms. It is a product of Dharma Labs, which was founded by Nadav Hollander (a former engineer at Coinbase and Google), and is backed by YCombinator and Polychain Capital.

The Dharma Protocol’s central aim is to provide an alternative to the traditional debt industry, which suffers from systemic misgovernance and a lack of transparency. The protocol is executed through a system of debt orders, which are transferred, underwritten and managed through Ethereum smart contracts in a peer-to-peer manner.

5. Colendi

Colendi is an Ethereum-based microcredit platform that aims to challenge conventional methods of credit scoring. Similar to microcredit organizations such as Tala (a dominant player in the non-blockchain market), Colendi leverages blockchain technology in order to extend microcredit opportunities on a global scale. The platform’s headquarters are in Switzerland, with offices in Turkey and China, and its official launch was in early 2019.

Colendi seeks to serve the world’s underbanked individuals and businesses, who are estimated to comprise almost 40% of the global population. Lack of access to adequate banking services is a problem that, according to Colendi, extends even to the developed world. They seek to mitigate the issue with their platform, which is divided into a protocol and non-protocol layer (the former consists of borrowers, lenders, merchants and data partners; while the latter consists of contributors, data integrators and validators).

Conclusion

The advent of Ethereum and smart contracts has arguably served as the killer app for decentralized finance. DeFi use cases now vary widely and are diversifying with every new innovation. While the 5 DeFi projects mentioned above are among the foremost industry leaders, there are plenty of other major players who will undoubtedly become more well-known as decentralized finance increases its influence in global markets.

The post Top 5 DeFi (Decentralized Finance) Projects appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Ethereum Whisper: A Detailed Guide

Web 3.0 is the decentralized evolution of the World Wide Web. The concept aims to replace centralized web applications with so-called decentralized applications (DApps), which are implemented on a trusted peer-to-peer (P2P) network without central points of control and central points of failure. In the Ethereum ecosystem, Web 3.0 is implemented in the form of three pillars, of which one is the Ethereum Whisper protocol, which is designed to bring about the emergence of DApps, and by extension Web 3.0, by acting as a secure and decentralized messaging protocol.

The first pillar is smart contract technology, which is run on the Ethereum blockchain as a trusted immutable backend. With smart contracts, the code of the decentralized application is executed on top of a trusted P2P protocol, instead of a web server. The second pillar, decentralized storage, can be found in the form of Swarm. This allows the off-chain parts of DApps, such as web interfaces and larger pieces of data, to be stored in a decentralized manner, eliminating the need for centralized file storage or databases.

The third element of the Web 3.0 vision involves privacy-focused secure messaging. There are a number of situations in which DApps need to communicate through a message bus outside the context of blockchain transactions. Message buses allow applications or users to interchange messages point-to-point or in a broadcast fashion. Traditionally, this has been achieved by centralized message servers. Reasons for DApps to keep communication off-chain include:

  • Privacy.
  • Temporary limits for the validity of a message (a time-to-live property).
  • The cost of on-chain transactions.

In Ethereum, the Whisper protocol is designed to take on the role of a secure off-chain message bus.

Calleum Labs The Whisper Protocol

Ethereum Whisper is designed as a flexible and secure messaging protocol that protects user privacy. The protocol follows a “darkness” principle, meaning that it obscures message content and sender and receiver details to observers, which also means that this information cannot be gained through packet analysis. This principle is akin to the Thor projects effort to provide anonymous web browsing.

Messages are encrypted by default either asymmetrically or symmetrically. Asymmetric encryption uses public keys for encryption and private keys for decryption. This form of encryption is used for one-to-one communication. While symmetric encryption facilitates one-to-many messages using a single encryption and decryption key. Messages are received by a participant if they can be decrypted. Thus, the owner of private keys can receive messages destined only for them. One-to-many communications can be received by anyone in possession of the correct symmetric key. Of course, the strong link with Ethereum means that all participants already have public/private key pairs, making this fully encrypted model possible.

Protocol Details

The Ethereum Whisper protocol implementation builds on top of the RLPx transport protocol that is internally used by Ethereum for communication between nodes. While the protocol has been designed for relatively low latency (< 5 seconds), it is not suitable for real-time communication. Due to the underlying broadcast nature of the protocol, Whisper also has bandwidth limitations. The maximum size of a message is capped at 64K Bytes, although most messages are much smaller in practice.

Whisper messages also have a time-to-live (TTL) associated with them, meaning that they expire after a certain time. A TTL property ensures messages are only valid for the specified time and will not be received after the timeout. TTL is useful in a number of situations, for example, when broadcasting a temporary price offer in trading.

In order to avoid spam, nodes must execute a proof of work algorithm to send a message. The amount of work to be performed is relative to the size and TTL of a message.

Messages within Whisper are encoded in an envelope with the following fields:

  • Version: Version number of the protocol. This is used to identify the decryption format.
  • Expiry: The expiry time of the message in the form of a UNIX timestamp.
  • TTL: The time to live in seconds.
  • Topic: Arbitrary data field that can be used as an indication of whether a message is “of interest” to a node.
  • AESNonce: A unique number that is used by symmetric encryption in combination with the key.
  • Data: The encrypted payload of the message.
  • EnvNonce: A number used by the proof of work algorithm.

One aspect to note with this design is that the topic field is not a traditional identifier, such as a “subject line”. It can instead be used by a so-called bloom filter to give a probabilistic indication of whether a node should be interested in attempting to decrypt a message. This is needed because the darkness principle impedes nodes from knowing whether they are a recipient to a message until they have tried decrypting it using the keys at their disposal.

Running Ethereum Whisper

Etheruem Whisper is implemented in the Go Ethereum client (Geth). However, it is disabled by default and needs to be activated with the following command line flag:

  • geth –shh

As the protocol is meant to be used by DApps internally, rather than end users, it has to be used programmatically through the RPC API. Javascript bindings are included in the web3.js library.

The main alternative to Geth, the Parity Ethereum client, also implements Whisper.

The post Ethereum Whisper: A Detailed Guide appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
What is Compound Finance? A Detailed Beginner’s Guide

Compound Finance is an algorithmic, open-source protocol that allows for the creation of money markets on the Ethereum blockchain. Individuals and institutions are able to earn interest on digital assets that they supply to the protocol. Whilst those that are seeking to borrow digital assets can do so directly from the protocol itself, without having to negotiate with a counterparty or peer. The Compound Finance protocol can also be thought of as being a DeFi (decentralized finance) project, because the protocol seeks to innovate upon existing financial money markets, by constructing a novel market model that is frictionless, efficient and decentralized.

A core objective of the Compound Finance protocol is to provide individuals with the ability to ‘trade the time value’ of a digital asset. This derives from the financial concept, ‘the time value of money’, which stipulates that money in the present is worth more than the identical sum of money that is received in the future. This is due to the earning capacity of money received in the present; money received in the present can be invested, thus, enabling that money to earn a return and generate a larger sum of money in the future. One way to generate such a return is by lending a given amount of money, upon which the lender can then earn a return in the form of an interest rate that is attached to the loan.

It is by innovating on the lending and borrowing process that Compound Finance seeks to address a problem found with holding digital assets, which is financial yield. Yield is the income that is returned on an investment. For example, yield for traditional assets would be the dividends that are received from holding shares in a company, coupon payments on a bond, or rental income from a leased property. Yield is separate to investment return (also known as total return), which is the financial gain or loss on an investment over time. Yield that is generated from an investment does not require one to sell in order to unlock the underlying value of an asset. According to the Compound Finance whitepaper, one major flaw that exists with blockchain assets is that:

‘Blockchain assets have negative yield, resulting from significant storage costs and risks (both on-exchange and off-exchange), without natural interest rates to offset those costs. This contributes to volatility, as holding is disincentivized.’

The Compound Finance protocol seeks to address this problem by attempting to bridge the gap between lenders that are seeking to earn a return on non-yielding digital assets, and borrowers that are seeking to use borrowed assets for productive or investment use.

Compound Finance Protocol

Compound is the protocol that establishes money markets on the Ethereum blockchain. In traditional finance, money markets are where financial instruments with high liquidity and short maturities are traded. Money markets are primarily used by large institutions and corporates as a means for borrowing and lending in the short term. In the context of the Compound Finance protocol, money markets are pools of tokens with algorithmically determined interest rates that are based on the supply and demand of the token in a given money market. Money markets on the Compound protocol also contain a transparent and public balance sheet that keeps a record of all transactions and historical interest rates.

Participants of the protocol can largely be placed into two groups, suppliers and borrowers. Suppliers will supply (or lend) their funds to the protocol, and in return, be rewarded in the form of interest rate payments. Whilst those who wish to borrow can do so from the digital assets that have been supplied to the protocol. Participants can choose to supply or borrow from any money market that is supported by the protocol, which at the time of writing is: BAT, DAI, REP (Augur), WETH (Wrapped Ether) and ZRX (0x).

Compound Finance: Supplying Tokens

The lending mechanism for the Compound Finance protocol differs to other peer-to-peer platforms in that, with the Compound Finance protocol, a user’s token is not matched and lent to another user. Instead, those wishing to lend, will lend to the protocol itself. The compound protocol then aggregates the supply of lent funds, resulting in a high level of liquidity for that money market. This lending mechanism also means that users that do decide to supply funds to the protocol are able to withdraw their tokens at any time. They do not have to wait for a specific loan to mature in order to recover their lent funds. Assets that are supplied to the protocol will accrue interest based on the supply interest rate that is unique to that particular asset.

Compound Finance: Borrowing Tokens

The borrowing mechanism implemented by Compound differs to alternative peer-to-peer platforms. In these platforms, borrowing will often be accompanied by negotiation with the counterparty. For example, negotiating the maturity date or funding period. With the Compound Finance protocol, users are able to borrow an asset directly from the protocol by simply specifying the asset that they wish to borrow. Each money market will also have a floating interest rate that determines the cost of borrowing an asset.

The Compound Finance protocol also enforces a rule that stipulates that a user’s account must have a balance that more than covers the amount of borrowed funds. This rule is known as the collateral ratio, and a user cannot initiate action, for example borrowing or withdrawing assets, that would bring a user’s account value below the collateral ratio.

The Compound Finance protocol also utilizes a ‘Price Oracle’, which keeps track of the current exchange rate of each supported digital asset on the protocol. The responsibility of setting the value of assets on the protocol is delegated to a committee, which pools the prices of supported assets from the top 10 exchanges in the cryptocurrency space. These exchange rates are used by the protocol to determine the borrowing capacity and collateral requirements for an account, and any other function that requires calculating the value equivalent of an account on the protocol.

Interest Rates

The interest rate that is set when a user supplies the protocol, or when a user borrows from the protocol, is one that is determined algorithmically, which is based on the supply and demand of the asset in a given money market. As a result, when there is a lot of liquidity in a particular money market (high supply and low borrowing demand), then interest rates in that market will be low. Conversely, when there is a shortage of liquidity (low supply and high borrowing demand), then interest rates will likely be high. This interest rate mechanism differs to alternative peer-to-peer lending platforms, where individual suppliers or borrowers usually have to negotiate over terms and rates of loans.

Liquidation

If the total value of a user’s supplied assets, divided by the value of their outstanding borrowing, declines below the collateral ratio, then the user’s account is subject to liquidation by other users of the protocol. If liquidation occurs, then the liquidator may repay some or all of an outstanding borrow on behalf of the individual that is being liquidated (also known as the liquidatee). This has the effect of bringing the liquidatee’s borrow balance back in line with the collateral ratio. In return for initiating a liquidation, the liquidator receives a discount that is known as the ‘Liquidation Discount’. This discount represents the percent value that a user receives when initiating a liquidation.

Money Market Smart Contract

Money markets on the Compound Finance protocol are underpinned by the Money Market smart contract. It is by use of this smart contract that one is able to interact with the Compound protocol. The Money Market smart contract possesses the following functionalities that enable the lending and borrowing process on the protocol:

Supply

The supply function allows a supplier to transfer an asset into the money market. That asset then begins to accumulate interest based on the current supply interest rate for the asset.

Withdraw

The withdraw function transfers a user’s asset from the money market back to the user, which has the effect of reducing the user’s supply balance in the protocol.

Borrow

The borrow function transfers an asset from the money market to the user, which has the effect of commencing the accumulation of interest based on the current borrow rate for the borrowed asset.

Repay Borrow

The repay borrow function transfers a borrowed asset into the money market, which has the effect of reducing the user’s borrow balance.

Account Liquidity

Account liquidity is the total value of a user’s supply balance subtracted by the total value of that user’s borrow balanced, multiplied by the protocol collateral ratio. Users who possess a negative account liquidity will not be able to withdraw or borrow any assets until their account liquidity is brought back to positive. This can be achieved by either supplying more assets to the protocol or paying back any outstanding borrowed assets. A negative account liquidity also means that the user’s account is subject to liquidation.

Further information regarding the functionality of the Money Market smart contract.

Market Status and Governance

Each money market on the Compound Finance protocol can be in one of three states:

  • Unsupported
  • Supported
  • Suspended

Each new money market will begin in the unsupported state and, depending on the actions of the administrator, may then transition to the supported state. Once a market is in the supported state, any user wishing to supply or borrow from the market may do so. However, if a money market must be closed for any reason, as determined by the administrator, then that market will become suspended. If a market becomes suspended indefinitely, then all borrows of that asset can be liquidated.

The governance model for Compound is to start off as being under centralized control. However, it is intended that, over time, control of the protocol will transition to the community. The rights that are capable of being exercised by the administrator or governance committee include:

  • The ability to choose a new administrator, such as a DAO
  • The ability to set the interest rate model per market
  • The ability to support, suspend or unsuspend a market
  • The ability to delegate which entity may set oracle prices
  • The ability to withdraw the equity (earned income) of the protocol

It Is expected that, at some point in the future, these rights will be moved to a DAO (Decentralized Autonomous Organization) that is controlled by the community.

The post What is Compound Finance? A Detailed Beginner’s Guide appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Ethereum Swarm: A Detailed Guide

Blockchains, such as Ethereum, allow the implementation of decentralized applications (DApps). The main idea of DApps consists of deploying an application in the form of smart contracts on an immutable blockchain, therefore eliminating trusted application servers and single points of failure. Ethereum Swarm is designed to enhance the emergence of DApps, and by extension the Web 3.0 paradigm, by serving as a decentralized data storage solution.

However, it is surprisingly difficult to make the Web 3.0 model workable in a purely decentralized way. There are two main reasons for this. Firstly, interacting with smart contracts is complicated and provides a very poor user experience. For this reason, most DApps provide a web interface, consisting of an off-chain front-end that is hosted on a traditional web server and served over the HTTP protocol. This, of course, introduces a trusted centralized component into the setup. Secondly, it is very expensive to store large amounts of data on a blockchain, which is why DApps usually require a way of storing some of their data off-chain. Again, using a database management system or a traditional filesystem goes against the decentralized model.

Decentralized Storage

A solution to this dependency on centralized components can be found in decentralized storage solutions. The idea is simple: a peer-to-peer (P2P) network of collaborating nodes is used to pool resources. The P2P network acts as a distributed cloud storage solution with built-in redundancy. In theory, any type of data can be hosted and served from such a decentralized network, including off-chain DApp data and the files constituting the front-end for DApps.

Possibly the most well-know distributed storage solution is the Interplanetary Filesystem (IPFS), which uses a distributed hashtable data-structure to store content across a network of nodes. However, IPFS content is not guaranteed to be available, unless the original data owner keeps serving it from its own host. This is due to the fact that content propagation through the network is prioritized according to popularity and unpopular content may be garbage collected. The lack of incentives or nodes to host content is a general problem in decentralized storage solutions.

Ethereum Swarm Architecture

Swarm is Ethereum’s implementation of a decentralized file storage network. It is supported by the Ethereum Geth client and interacting with the storage network is closely linked to the Ethereum blockchain and requires an Ethereum account.

Swarm Distributed Storage Model

The above figure illustrates how Ethereum Swarm distributes data across the P2P network. Data is split up into blocks called chunks, which have a maximum size limit of 4K bytes. The network layer is agnostic to what these chunks represent, for instance, whether they are part of a file or any other piece of data. Chunks are distributed across the network and addressed by a 32-byte hash of their content. This ensures that data integrity can be verified, but, this introduces a problem with storing content that may be modified. Hash addressing is also not very user-friendly. For this reason, another layer, the Ethereum Name Service (ENS) allows users to register human-readable names for their content. ENS is implemented as a smart contract on the Ethereum network and can be considered the equivalent of the domain name service (DNS) that facilitates content naming in traditional internet services.

Incentive Layer

Ethereum Swarm differentiates itself from IPFS in that it does not just reference and (potentially cache) content made available on a content owner’s own storage. Instead, it actually constitutes a cloud service onto which content can be uploaded.

Currently, there is no guarantee uploaded content will remain available, as nodes may join and leave the network at will, or even reduce their storage capacity. A future incentive layer is planned, in order to compensate node owners for offering storage space. This is made possible by the close integration with Ethereum.

Using Swarm

To connect to Ethereum Swarm a running instance of Geth is required. The Swarm client itself can be obtained from the Swarm download page for different platforms.

Once the Swarm executable has been installed, you can then connect to the network using an existing account managed by the running Geth instance:

  • swarm –bzzaccount <accout>

Swarm then provides an endpoint on port 8500. Navigating to http://localhost:8500 in a browser will open up a search box for the Swarm network. More advanced usage options can be found in the official documentation.

Of course, web browsers do not currently support Swarm’s protocol natively. Therefore, the Ethereum Foundation provides a gateway service to allow Swarm hosted content to be accessed in the absence of a local Swarm client. The gateway can be accessed by placing content addresses in the following URL:

  • https://swarm-gateways.net/bzz:/<address>/

The post Ethereum Swarm: A Detailed Guide appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
What is Uniswap? A Detailed Beginner’s Guide

Uniswap is an Ethereum-based protocol that is designed to facilitate automatic digital asset exchange between ETH and ERC20 tokens. Uniswap is completely on-chain, and individuals can make use of the protocol as long as they have MetaMask installed. Uniswap can also be thought of as being a DeFi (decentralized finance) project, because it seeks to leverage its decentralized protocol in disintermediating middle-men that are involved in the financial process of digital asset exchange.

Uniswap consists of two types of smart contracts: an exchange contract and a factory contract. These contracts are written in the Vyper smart contract programming language, and are core to the functioning of the Uniswap protocol. An exchange contract supports exactly one ERC20 token, and each exchange contract holds a reserve of ETH and their supported ERC20 token. This means that trades executed on a given exchange contract is based on the relative supply of ETH and ERC-20 tokens that are found in the contract. Trades that are executed on an exchange contract also allow for direct ERC20 to ERC20 trades using ETH as an intermediary.

The factory contract can be used to deploy a new exchange contract, thus, any ERC20 token that does not yet have an exchange contract can create one using the factory contract. The ‘createExchange()’ function allows any user on Ethereum to deploy an exchange contract using the factory contract. It is also important to note that the factory contract serves as a registry for Uniswap exchange contracts, meaning that the factory contract can be used to look up all token and exchange addresses that have been added to the system. The factory contract does not carry out checks on a token when an exchange contract is launched (aside from the one-contract-exchange-per-token limit), thus, users should only interact with exchange contracts that they have full confidence in.

Uniswap Liquidity

The design architecture of the Uniswap protocol differs to the model found within traditional digital asset exchanges. Most traditional exchanges maintain an order book and use that to match buyers and sellers of a given asset. Uniswap on the other hand, utilizes liquidity reserves in facilitating the exchange of digital assets on its protocol. The reserves in exchange contracts are supplied by a network of liquidity providers. These liquidity providers deposit an equivalent value of ETH and ERC20 token into the corresponding ERC20 token’s exchange contract. The first liquidity provider to add liquidity to an exchange contract will initially set the exchange rate between ETH and the exchange contract’s associated ERC20 token. The liquidity provider does this by depositing what they believe to be an equivalent value between ETH and the exchange contract’s ERC20 token. If the value set by the liquidity provider is not consistent with the wider market, then arbitrage traders will bring the value between ETH and the ERC20 token to an exchange rate that the market deems correct. All subsequent liquidity providers thereafter will then deposit liquidity using the exchange rate at the time of their deposit.

Uniswap also makes use of so called ‘liquidity tokens’, which are in themselves ERC20 compliant. These tokens can be thought of as being a representation of a liquidity provider’s contribution to an exchange contract. The rationale behind Uniswap’s one-contract-exchange-per-token limit is to encourage liquidity providers to pool their liquidity into a single reserve. Uniswap will mint liquidity tokens in order to track the relative proportion of total reserves that each liquidity provider has contributed. Liquidity providers are able to burn their liquidity tokens at a time of their choosing, so that they can withdraw their proportional share of ETH and ERC20 tokens from the exchange contract.

Liquidity providers can also choose to sell or transfer their liquidity tokens between accounts without having to remove liquidity from the exchange contract. However, Uniswap liquidity tokens are strictly specific to an exchange contract. There is no single underlying native digital asset that is associated with the Uniswap protocol. Liquidity providers are also able to deposit liquidity into an exchange contract by calling the ‘addLiquidity()’ function. In exchange for supplying liquidity, liquidity providers will receive a share of transaction fees when a trade is executed.

Trading on Uniswap: ETH ⇄ ERC20 Trades

One type of trade that can be executed on the Uniswap protocol is exchanging ETH for any given ERC20 token. As mentioned before, the exchange rate between ETH and an ERC20 token is based on the relative size of the respective assets’ liquidity pool within the exchange contract. The exchange rate is underpinned by Uniswap’s invariant formula: ETH pool * token pool = invariant. This invariant is held constant during the execution of any trade on the Uniswap protocol. Furthermore, the invariant will only change when liquidity is added or removed from the exchange contract upon which a trade is being executed.

Example ETH ⇄ BAT: Bob wishes to initiate a trade such that he exchanges his 1 ETH for the ERC20 token, BAT (Basic Attention Token). Bob will execute this trade using an existing exchange contract on the Uniswap protocol. Liquidity providers have deposited an amount of ETH and BAT into the exchange contract, which for the purposes of this example, is 10 ETH and 500 BAT. The underlying invariant formula is set to: ETH pool * BAT pool = invariant.

ETH pool = 10
OMG pool = 500
Invariant = 10 * 500 = 5,000

Bob will initiate his trade by sending 1 ETH to the ETH pool in the exchange contract, upon which a 0.3% liquidity provider fee is taken out. The remaining 0.997 ETH is added to the ETH pool. The invariant is then divided by the new amount of ETH in the liquidity pool for the purposes of determining the new size of the BAT pool. The remaining BAT tokens are then sent to the buyer, which in this case is Bob.

Bob sends: 1 ETH
Fee = 0.003 ETH
ETH pool = 10 + (1 – 0.003) = 10.997
BAT pool = 5000/10.997 = 454.67
Bob receives: 500 – 454.67 = 45.33 BAT

The liquidity provider fee, which was previously taken out when Bob initiated the transaction, is now added back into the liquidity pool. This functions as a pay-out to liquidity providers, which can be collected when these providers remove their liquidity contribution from the market. Because the fee is added after price calculation, the invariant increases gradually with each trade that is executed on the exchange contract, making the act of investing liquidity into an exchange contract a profitable one for liquidity providers.

ETH pool = 10.997 + 0.003 = 11
BAT pool = 454.67
new invariant = 5,001.37

In this trade, Bob received a rate of 45.33 BAT/ETH.

1 ETH in
45.33 BAT out
Rate = 45.33 BAT/ETH

Trading on Uniswap: ERC20 ⇄ ERC20 Trades

Another type of trade that can be executed on Uniswap is exchanging one type of ERC20 token for another type of ERC20 token. Because ETH is utilized as a common pair for all ERC20 tokens, Uniswap uses ETH as an intermediary asset for a direct ERC20 to ERC20 trade. Uniswap makes it possible to, for example, convert from BAT to ETH on one exchange contract and then from ETH to OMG in another exchange contract, all within one single transaction.

This formula functions very much like a regular market, in that the more tokens you buy the higher the marginal exchange rate that one would have to pay for each additional unit of a token that is bought.

Fee Structure

The Uniswap fee structure for trades executed on the protocol are as follows:

  • ETH to ERC20 trade: 0.3% fee paid in ETH
  • ERC20 to ETH trade: 0.3% fee paid in ERC20 token
  • ERC20 to ERC20 trade: 0.3% fee paid in ERC20 token (for ERC20 to ETH swap) and 0.3% fee paid in ETH (for ETH to ERC20 swap).
Token Exchange Rates

The invariant formula that is used by Uniswap in determining the exchange rate between tokens is taken from a post published by Vitalik Buterin in March 2018. In this post, the exchange rates for an ERC20 token are calculated in accordance with the following formula: x * y = k. k is a constant that does not change, and x and y signify the quantity of ETH and ERC20 tokens that are available on a particular exchange, which in the case of Uniswap, would be the amount of ETH and ERC20 tokens that are available in a given exchange contract. With this formula, the exchange rate of a given token will always be at a particular point on the resulting curve of the above formula.

The x * y = k formula is an integral part of the Uniswap protocol, and Buterin, using the graph shown below, describes it in the following way:

With the formula, a contract, which in this case would be a Uniswap exchange contract, would hold x amount of token A and y amount of token B. This contract would always maintain the invariant such that x * y = k. Any individual can buy or sell coins by effectively shifting the market maker’s position on the x * y curve. Shifting the market maker’s position to the right would mean that the amount by which a trade moves right is the amount of token A the trader would have to put in. Conversely, the amount by which the market maker’s position shifts downward is how much of token B the trader should get out.

Assuming that token B is ETH and token A is any given ERC20 token, we can see how they would function using the x * y = k formula. If Alice decides to purchase a large amount of a given ERC20 token, this would result in a shortage of that ERC20 token and an increased amount of ETH. The result of Alice’s purchase would be to move the exchange rate to a different point on the x * y = k curve. The red dot would shift to the left, meaning that purchasing more of a ERC20 token would become more expensive. The relative supply of ETH and an ERC20 token in a Uniswap exchange contract can be thought of as being a reflection of the supply and demand of that ERC20 token, which ultimately sets the exchange rate price.

As mentioned earlier, the first deposit of liquidity into an exchange contract is not determined by an exchange rate. Instead, the liquidity provider will deposit an amount of ETH and ERC20 tokens that reflect what they think the exchange rate between ETH and the ERC20 token is. If the value of ETH and the ERC20 token is regarded as being too cheap or too expensive, then arbitrage traders will be incentivised to bring that value to a point that the market deems as correct.

Uniswap and Arbitrage Trading

It is important to note that, although Uniswap is a decentralized on-chain digital asset exchange, it does not exist to replace centralized exchanges. In the event that the exchange mechanism on Uniswap becomes skewed, then there must exist a mechanism by which this can be corrected. This mechanism exists in the form of arbitrage trading.

Arbitrage trading is a strategy that can be best understood as a trader that takes advantage of the price differential that exists between two markets. In the case of cryptocurrency, this price differential can be found in the differences in price of a digital asset between cryptocurrency exchanges. If a trader identified an opportunity for arbitrage trading, then they would purchase a digital asset in one exchange, and then simultaneously sell it on another cryptocurrency exchange. Arbitrage trading is vital to the functioning of Uniswap because traders can leverage alternative exchange rates that exist in other cryptocurrency exchanges in correcting any skew in prices that may occur on Uniswap.

Uniswap and Gas

One advantage of using the Uniswap protocol to exchange digital assets is the fact that it is very gas efficient. The gas cost incurred when executing a trade on Uniswap are comparatively cheaper than alternative decentralized exchanges. As the gas benchmark shows below: ETH to ERC20, ERC20 to ETH, and ERC20 to ERC20 swaps are significantly cheaper than exchanges such as Bancor, EtherDelta etc.

Gas efficiency is just one of the advantages of the Uniswap protocol, more advantages include:

  • Uniswap is decentralized, so, it does not rely on third parties for its operation. Furthermore, Uniswap is freely accessible to anyone wishing to connect to the protocol.
  • Cost of executing a trade on Uniswap is relatively cheap compared to other digital asset exchanges.
  • Uniswap allows any user to create an exchange contract for any given ERC20 token.

Uniswap, however, does come with its limitations:

  • Uniswap does rely on arbitrage trading in order to keep the exchange prices of tokens on the protocol in check. This means that Uniswap is relying on the existence of other digital asset exchanges to keep exchange rates balanced.
  • Uniswap is still very much experimental, more development is required on the protocol to see just how effective it can be in facilitating digital asst exchange.
Conclusion

To conclude, Uniswap represents a significant step in enabling digital asset exchange in the ecosystem, by making the process of exchanging assets a much more efficient one. Uniswap is still very much in its early days, however, it will be interesting to see how this novel digital asset exchange protocol evolves in the future.

The post What is Uniswap? A Detailed Beginner’s Guide appeared first on Mycryptopedia.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Ethereum Geth: Installing and Running a Node

In order to participate in a blockchain, there usually is a need to run some form of client software that implements the features required to become a node. Even for actions such as simply sending a transaction to the network, a node is usually required. Participation in the Ethereum blockchain can be done by making use of Ethereum Geth, the command line interface for running a node on the Ethereum network, which has been implemented using the Go programming language.

The goal of Ethereum has always been to provide a number of different client software implementations, written in different programming languages, that will foster a diverse ecosystem within Ethereum. However, by far the most mature implementation of Ethereum is “Go Ethereum”, abbreviated to Geth. While there are other clients, notably Parity, Geth can be seen as the defacto reference implementation for running an Ethereum node.

In this article, we discuss Ethereum Geth, its architecture, and how it can be used to run an Ethereum node or light client.

Ethereum Geth Architecture

The above diagram illustrates the architecture of the Ethereum Geth client at a high level. At the lowest level, a peer-to-peer (P2P) protocol is in charge of communication on the network, and is also responsible for discovering peers on the network. The communication mechanisms used at this level is based on the Gossip algorithm. This classic distributed systems algorithm stems from the 1980s, and models network communication based on the way epidemics or rumors spread through the population. The idea is simple but powerful: nodes on the network relay messages to other nodes that they are directly connected to, these nodes can be regarded as being their neighbours. Eventually, every node should receive relayed messages as they spread throughout the entire network.

On top of the P2P mechanism, Ethereum Geth implements three main modules. Apart from the actual Ethereum client implementation, Geth also includes Swarm and Whisper. Swarm is a distributed file system, akin to the Interplanetary Filesystem (IPFS), which is aimed at storing large amounts of data cheaply and in a decentralized manner. Whisper is a decentralized messaging protocol that allows communication between endpoints without relying on blockchain transactions.

The actual Ethereum-specific module implements the Ethereum Virtual Machine for transaction processing. The blockchain state is stored in the LevelDB key-value database. In order for applications to connect to a running Geth instance, a JSON RPC API is exposed. This can be used to connect directly, or through a language-specific library, such as web3.js.

Installation

Installing Geth is relatively straightforward. Binary packages for Mac OS X, Windows and Linux can be found on the projects latest release download page. These packages include stand-alone pre-compiled binaries that can be run out of the box in most cases. It is also possible to use existing operating system package managers, such as Homebrew on Mac OS X:

  • brew tap ethereum/ethereum
  • brew install ethereum

Purists, or users of unusual binary platforms, may also build Ethereum Geth from source. This can even be used to install Geth on small devices, such as a Raspberry Pi (light-client only). To do so, a Go compiler is required. Installation of Go is platform dependent, but pre-built packages exist for all major operating systems.

Once Go is installed, it is a question of downloading the latest Geth source package from the release page or cloning the GitHub repository:

  • git clone https://github.com/ethereum/go-ethereum

Geth can then be built by running the following command within the source code directory:

  • make geth

The resulting binary can be run from anywhere, but it is usually a good idea to move the executable into a common system directory within the operating system’s execution path, to ensure it can be run the same way as any other operating system binary.

Creating Accounts and Connecting to the Ethereum Blockchain

Once Geth is installed, it can be run by typing:

  • geth

However, there are a few things worth considering first. First of all, no Ethereum client can do much without an Ethereum account. Geth can import existing private keys or create new ones. A new key pair is created with the following command:

  • geth account new

The other important issue is the sync mode that should be used. Geth can only be used once it has synced up its state with the blockchain. This can take a long time, depending on how much state is supposed to be downloaded. There are three sync modes that can be set with the following command:

  • –syncmode “mode”

Options for sync mode are “fast”, “full” or “light”, with the software defaulting to “fast” when no sync mode is specified. “Full” downloads all block headers, block data, and validates all transactions. Choosing “fast” accelerates this by only verifying the most recent transaction history on the Ethereum blockchain. Finally, “light” downloads the current state, but does not do any verification. A light node will rely on its peers to process and verify transactions that are initiated on the blockchain.

Running Ethereum Geth

Once Geth is running, one can interact with it through the JSON RPC interface. An easy way to do this is to use the Geth executable itself to connect to a running instance:

  • geth attach

This opens up a JavaScript console that allows for web3.js commands. For example, to check whether the running instance has already synced up to the Ethereum network, the following command can be used:

  • > web3.eth.syncing

A list of accounts can be seen with the following command:

  • > eth.accounts

Of course, Geth can also be interacted with from other programming languages that support bindings for the JSON RPC API, or you can send JSON-formatted commands to the API directly. Geth exposes the API on port 8545, but it may have to be enabled at start-up by adding the following command line option:

  • geth –rpc

In fact, Geth supports a number of useful command line options to change the default behavior, such as the network it connects to. A full list of options can be found in the official documentation.

The post Ethereum Geth: Installing and Running a Node appeared first on Mycryptopedia.

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview