Giter Site home page Giter Site logo

openst / mosaic-contracts Goto Github PK

View Code? Open in Web Editor NEW
115.0 33.0 31.0 10.94 MB

Mosaic-0: Gateways and anchors on top of Ethereum to scale DApps

Home Page: https://discuss.openst.org/c/mosaic

License: MIT License

Shell 0.30% JavaScript 66.27% Solidity 31.05% TypeScript 2.39%
ethereum simpletoken sharding ost metablockchain mosaic blockchain openst-protocol

mosaic-contracts's Introduction

๐Ÿ’  Mosaic Contracts

Build master Build develop npm version Discuss on Discourse Chat on Gitter

Mosaic is a parallelization schema for decentralized applications. It composes heterogeneous blockchain systems into one another. Decentralized applications can use Mosaic to compute over a composed network of multiple blockchain systems in parallel.

Mosaic enables building scalable blockchain token economies through the bidirectional transposition of ERC20 tokens on one blockchain, the origin chain, and a utility token representation on another blockchain, the auxiliary chain.

The protocol defines a set of actions that together perform atomic token transfers across two blockchains using gateway contracts. A gateway for a given EIP20 token is comprised of a EIP20Gateway contract on origin, a corresponding EIP20CoGateway contract on auxiliary, and and an ERC20 utility token contract on auxiliary that mints and burns utility tokens to atomically mirror tokens staked and unstaked on the origin chain.

Atomicity is achieved using a 2-phase message passing architecture between the chains. Messages are declared on the source chain, and confirmed on the target chain with Patricia Merkle proofs once the source chain is finalized. Once messages are confirmed on the target chain, they can efficiently progressed with a hashlock. Messages can also be reverted if they are not yet completed on the target chain.

You can read the draft of the mosaic whitepaper or the original OpenST whitepaper.

Instructions

For JS Consumers

Installation

npm install @openst/mosaic-contracts

Usage

// Load the contracts' meta-data from the package:
import { contracts } from "@openst/mosaic-contracts";

// Access the ABIs and BINs directly on the contracts. For example:
const anchorAbi = contracts.Anchor.abi;
const anchorBinary = contracts.Anchor.bin;

@openst/mosaic-contracts also includes the contract interacts.

Example of using the contract interacts.

import { Interacts} from "@openst/mosaic-contracts";

const anchor:Anchor = Interacts.getAnchor(web3, '0xAnchorContractAddress');
const gateway:EIP20Gateway = Interacts.getEIP20Gateway(web3, '0xEIP20GatewayContactAddress');

Example with Web3 contracts.

import { contracts } from "@openst/mosaic-contracts";

const jsonInterface = contracts.Anchor.abi;
const contract = new web3.eth.Contract(jsonInterface, address, options);

const anchor:Anchor = contract as Anchor;

For Direct Users

This section is only required if you want to set up a new mosaic chain.

Installation

git clone https://github.com/OpenST/mosaic-contracts.git
cd mosaic-contracts
npm run update # Runs `git submodule update --init --recursive && npm ci`
npm run compile:all

Usage

There is a deployment tool available for deployment and set-up:

node ./tools/blue_deployment/index.js

โš ๏ธ Note that this feature is still very experimental โš ๏ธ

Related Work

mosaic.js uses this package to provide a JavaScript abstraction layer of the mosaic contracts. You can use mosaic.js directly to deploy the contracts and interact with them.

Contributing

Set-up

git clone https://github.com/OpenST/mosaic-contracts.git
cd mosaic-contracts
npm run update # Runs `git submodule update --init --recursive && npm ci`
npm run compile:all
npm run ganache
npm run test

Guidelines

There are multiple ways to contribute to this project. However, before contributing, please first review the Code of Conduct.

We track our issues on GitHub.

To contribute code, please ensure that your submissions adhere to the Style Guide; please also be aware that this project is under active development and we have not yet established firm contribution guidelines or acceptance criteria.

Community

mosaic-contracts's People

Contributors

0xsarvesh avatar abhayks1 avatar benjaminbollen avatar gulshanvasnani avatar hobofan avatar jasonklein avatar noslav avatar schemar avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mosaic-contracts's Issues

Run truffle test with optimised compilation

As it stands OpenSTValue and OpenSTUtility are quite heavy for a smart contract, and they hit 5M gas and 8M gas for deployment as unoptimised code; To get a more realistic picture of actual gas consumption early-on in development, run truffle tests to also compile with 200 optimisation runs.

This slows down truffle test but it additionally makes it more stable as it avoids cascading out of gas errors on the testRPC framework.

Unit tests: reversion functions

Add unit tests for:

  • OpenSTValue.revertStaking
  • OpenSTValue.revertUnstaking
  • OpenSTUtility.revertMinting
  • OpenSTUtility.revertRedemption

Protocol integration test

End-to-end integration test scripts for deployment and integrated protocol steps.

  • truffle complete deployment process
  • Initialize Transfer to ST' Contract Address - @abhayks1
  • stake ST for ST' - @ben
  • propose and register Branded Token - @kushal-ladha
  • stake ST for BT - @abhayks1
  • transact with BT - @ben
  • unstake BT from different user - @kushal-ladha
  • unstake ST' from different user - @abhayks1
    --- stretch goals ---
  • protocol version upgrade - @ben

implement escrow revert

the funds that are put into escrow on calling OpenSTValue.stake and OpenSTUtility.redeem need to revert to the staker or redeemer after the unlockHeight is surpassed and the funds have not been processed.

Addresses #8

Migrate tests from SimpleTokenSale

Certain contracts used in SimpleTokenSale are also used in this repository. Where there are already tests for those contracts, they should be included in this repository and updated as needed. Those include:

  • OpsManaged.sol
  • Owned.sol
  • SafeMath.sol

Separate value and logic on Value or Utility chain

  • separate logic and value on both chains (SimpleStake.sol, STPrime.sol, BrandedToken.sol are ProtocolVersioned.sol for OpenSTValue.sol and OpenSTUtility.sol
  • proposeBrandedToken and registerBrandedToken onlyRegistrar on Utility chain, and registerUtilityToken onlyRegistrar on value chain; name reservation on utility chain
  • re-implement staking

clean-up: solc does not allow import of relative paths

problem for readability we had moved the contracts that get deployed on the utility chain into contracts/utilityChain/ and on the value chain into contracts/valueChain; but solc deliberately does not access other files on the filesystem without an explicit directory remapping (see ethereum/solidity#757)

solution as the reorg was done for readability, we can opt for a prefix to the contracts filename and collapse the directory structure back to contracts/; contracts that need to be deployed only on the value chain will have a prefix vc as vcMyContract.sol, and contracts that only need to be deployed on the utility chain will have a prefix uc; contracts that are deployed on both sides, or are inherited don't have a prefix.

ConfirmRedemptionIntent must fail if redeeming less than 1 STWei

failing unit test

1) Contract: OpenSTValue ConfirmRedemptionIntent fails to confirm when amountUT does not convert into at least 1 STWei:
     AssertionError: Did not throw as expected
      at Object.module.exports.expectThrow (test/lib/utils.js:79:5)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

Unit test 0.9.1 contracts

Contracts include the below (this list should be updated as there are changes to the composition of contracts):

Common

  • Core.sol
  • Hasher.sol
  • ProtocolVersioned.sol
  • Registrar.sol

Value Chain

  • OpenSTValue.sol
  • SimpleStake.sol

Utility Chain

  • BrandedToken.sol
  • EIP20Token.sol // protocol extensions
  • OpenSTUtility.sol
  • STPrime.sol
  • UtilityTokenAbstract.sol

Review JS/testing for best practice and consistency

JS unit and integration tests should be reviewed for consistency with (1) understood best practice and (2) intra- and inter-test consistency. This review applies to coding and logic patterns as well as to formatting and naming.

Where items are found to be inconsistent with best or consistent practice and there is not an overriding protocol reason for the inconsistency, issues should be added to revise those items (unless they can be more easily be made concurrently with the review).

Where inconsistent items are found (whether actually or seemingly inconsistent) but are retained in favor of the protocol, issues should be added to clearly document the reasoning for such inconsistency (unless they can be more easily be made concurrently with the review).

Review contracts for best practice and consistency

Smart contracts should be reviewed for consistency with (1) understood best practice and (2) intra- and inter-contract consistency. This review applies to coding and logic patterns as well as to formatting and naming.

Where items are found to be inconsistent with best or consistent practice and there is not an overriding protocol reason for the inconsistency, issues should be added to revise those items (unless they can be more easily be made concurrently with the review).

Where inconsistent items are found (whether actually or seemingly inconsistent) but are retained in favor of the protocol, issues should be added to clearly document the reasoning for such inconsistency (unless they can be more easily be made concurrently with the review).

A decision should be made as to how to best communicate any changes that impact the API.

UtilityToken - visibility features

Aliases for symbol and name:

  • Document specification (OpsManaged? Owned? Included w/r/t extraData)
  • Implement specification

extraData field getters/setters:

  • UtilityTokenAbstract.sol
  • UtilityTokenInterface.sol

Estimate: 8hr

Update Hasher arguments/returns names

Hasher.sol uses old arguments/returns names (i.e., escrowUnlockHeight). It should be brought in line with changes to OpenSTValue.sol and OpenSTUtility.sol.

Complete separation of value and logic for Redemption

builds on #5

  • re-implement OpenSTValue.processStaking
  • re-implement OpenSTUtility.redeem
  • re-implement OpenSTValue.confirmRedemptionIntent
  • re-implement OpenSTValue.processUnstaking
  • re-implement OpenSTUtility.processRedemption
  • add utility chainId to event StakingIntentDeclared
  • add value chainId to event RedemptionIntentDeclared
  • create OpenSTValueInterface.sol and OpenSTUtilityInterface for Registrar to use
  • add OpenSTValue.processStakingForced onlyRegistrar as temporary measure until the signature of OpenSTUtility.processMinting can be carried over
  • add OpenSTUtility.processRedemptionForced onlyRegistrar as temporary measure until the signature of OpenSTValue.processUnstake can be carried over

Rename UtilityTokenAbstract to UtilityToken

The unimplemented functions that previously existed in UtilityTokenAbstract have been removed, so the contract should be renamed "UtilityToken" and importing contracts/tests updated accordingly.

processStaking and processRedemption fallback

for v0.9.1 we put a fallback to execute processStaking and processRedemption by Registrar in advance of separating the signature confirmation from the transaction formulation.

addresses #8

for forcing cost

  • processStaking by Registrar
  • processRedemption by Registrar
  • unit test processStaking
  • unit test processRedemption

Reversion: nonce revert on utility

problem if redemption fails before it hits confirmRedemptionIntent redeemer would be left in locked state after revertRedemption with the nonce required on value chain surpassed on utility chain; therefore we want the redeemer to be able to restart after reverting; note, that this is not needed for revertMinting because nonce for mint is always behind or in sync with nonce on value chain;

(rejected) proposed solution When Staking-Mint is reverted; the nonce on OpenSTValue must not be reverted, but the nonce on OpenSTUtility can be reverted (where it is reduced by one, we have lost information of the previous nonce value)

When Redeeming-Unstaking is reverted; the nonce on OpenSTValue again must not be reverted, but the nonce on OpenSTUtility should be reverted (again, reduced by one)

to align the logic, the proposal is for OpenSTUtility to reduce the nonce by one on reversion calls; and not on OpenSTValue.

Protocol: implement transfer completion

Implement functionality that enables the protocol contracts to call ProtocolVersioned.completeProtocolTransfer.

For avoidance of doubt, this ticket also includes determining what should happen in terms of STPrime, which is currently deployed in the constructor of OpenSTUtility.

N.B.: ProtocolVersioned.completeProtocolTransfer does not have complete test coverage. Resolving this ticket should include re-instating and/or further tests of this functionality.

Estimate: 16hrs

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.