Unidirectional ethereum-contracts #50

denalimarsh · 2019-04-30T07:42:58Z

Changes to Peggy's ethereum contracts. Contracts only include functionality for unidirectional transfers of funds from Ethereum -> Cosmos and the branch is being actively used for testing transfer of assets from Ethereum to Cosmos. Existing work on secured unlocking in Valset.sol will be reincorporated once one-way transfers have been prototyped. If these changes are too breaking for master, wait and merge this PR once existing features have been reintegrated.

… funds from Ethereum to Cosmos

cwgoes · 2019-05-16T22:18:36Z

Thanks! Adding a written technical specification in Markdown would be helpful for review here.

…psten address

denalimarsh · 2019-05-27T00:45:40Z

Thanks! Adding a written technical specification in Markdown would be helpful for review here.

Added a project specification in the README.md of the /ethereum-contracts directory.

fedekunze · 2019-05-27T09:34:33Z

cc: @okwme can you review as well ?

fedekunze · 2019-05-27T09:39:42Z

ethereum-contracts/contracts/Peggy.sol


-        bytes32 hashData = keccak256(name, decimals);
-        require(Valset.verifyValidators(hashData, signers, v, r, s));
+        // Transfer item's funds and unlock it


what's an item in this context ?

An item refers to a single incoming transaction containing funds to be locked. Originally named 'escrow', the terminology was updated to 'item' to prevent confusion regarding the fact that the funds are not technically held in escrow for the unidirectional implementation. Happy to update the naming conventions again, should there be consensus about a more suitable name for an instance of locked funds.

I see. We use the term Msg on the SDK (See sdk.Msg and auth.StdTx for reference). I think that's a more accurate term for this case

Items aren't 1:1 with Msgs, as Items serve as storage for the original sender's funds and include a unique id which isn't currently reflected in the Msg sent on Cosmos - but I agree that 'Msg' is a much more accurate name than 'Item'. @cwgoes what are your thoughts on the naming conventions?

fedekunze · 2019-05-27T09:41:10Z

ethereum-contracts/package.json

@@ -1,5 +1,5 @@
 {
-  "name": "ethereum-contracts",
+  "name": "ethreum-contracts",


typo ?

Suggested change

"name": "ethreum-contracts",

"name": "ethereum-contracts",

Fixed, thanks for catching that.

cwgoes

Quick pass on the spec.

I'd like to see more detail on the individual steps involved in an Ethereum -> Cosmos transaction, and a list of the invariants which this bridge maintains (for example, that funds, once escrowed into the contract and minted on the Cosmos chain, cannot be un-escrowed - or, if that isn't the case, an explanation of what alternative property is being provided).

cwgoes · 2019-05-29T10:37:15Z

ethereum-contracts/README.md


-You can test the contracts using Truffle Testrpc in the console or Ganache UI.
+### Goals of the Smart Contracts
+1. Securely implement core functionality of the system such as asset locking and event emission without endangering any user funds. As such, this prototype does not permanently lock value and allows the original sender full access to their funds at any time.


What do you mean by "permanently lock"? Can the original sender unlock their original tokens even after they've sent tokens to Cosmos?

Correct. The original sender can withdraw tokens using withdraw(bytes32 id) while the contract's relayer can return tokens to the item's original sender using unlock(id). This is intended behavior for this stage of the project to protect any user funds should someone attempt to deploy the contracts to the mainnet; once the bridge has undergone robust testing the withdraw() function will be removed entirely and the unlock() function will be contingent on approval from the validator set.

I've updated the project specification to state that this project specification focuses on the role of 'Peggy', the Smart Contract system deployed to the Ethereum network, and is meant to contextualize its role within the bridge. Specifications detailing the structure and step=-by-step process of the non-Ethereum components (Relayer service, EthOracle module, Oracle module) will soon be available in the cosmos-ethereum-bridge repository.

ethereum-contracts/README.md

cwgoes · 2019-05-29T10:38:38Z

ethereum-contracts/README.md


-![alt text](./img/ganache_setup.png "Ganache Setup")
+### System Process:
+1. Users lock Ethereum or ERC20 tokens on the Peggy contract, resulting in the emission of an event containing the created item's original sender's Ethereum address, the intended recipient's Cosmos address, the type of token, the amount locked, and the item's unique nonce.


"created item" is not clear - what "item" is being referred to? What is the nonce? Is this a sort of packet?

Yes, an Item is a struct containing information about a unique incoming transaction which executes the lock() function. Due to confusion about the name, we should rename the struct to something more descriptive. How about 'LockedTokens' or 'Deposit'?

The nonce is a global variable which protects Peggy against possible replay attacks so that an item's funds can only be unlocked once. Consider this attack scenario:

An adversary locks X ETH into the contract (move from Ethereum to Cosmos Zone).

He then requests the reverse operation (move from Cosmos Zone to Ethereum).

After collecting the validator signatures, the relayer creates a transaction calling the unlock function for the amount X to sent to the user.

The adversary observes the transaction on the blockchain, and copies the signatures

The adversary, having already received X ETH, creates another transaction calling unlock directly himself for the amount X and replaying the captured signatures.

The amount X is transferred to the adversary again

The attacker can repeat this attack until the contract has been drained of ETH.

Deposit sounds great - and a nonce makes sense for replay prevention, agreed.

ethereum-contracts/README.md

cwgoes · 2019-05-29T10:40:15Z

ethereum-contracts/README.md


-Copy it and on in a separate tab in the console:
+## Other Considerations
+We decided to temporarily remove the validator set from this version of Peggy, our reasoning being that system transparency and clarity should take precedence over the inclusion of future project features.


What do you mean? That there still is a validator set - just not the same as the Tendermint validator set?

Correct. This refers to the validator set from Valset.sol, which was removed from the Smart Contracts for the unidirectional implementation. I've updated the section to be more explicit.

ethereum-contracts/README.md

cwgoes · 2019-05-29T10:41:55Z

ethereum-contracts/README.md


-## Installing dependencies
+## Project Summary
+Unidirectional Peggy is the starting point for cross chain value transfers from Ethereum to Cosmos as part of the Ethereum Cosmos Bridge project. The smart contract system accepts incoming transfers of Ethereum and ERC20 tokens, locking them while the transaction is validated and equitable funds issued to the intended recipient on Cosmos.


Can this part clarify that "Cosmos" is a specific bridge chain running Tendermint consensus and custom modules?

By itself, "Cosmos" refers to the network as a whole, not a particular blockchain.

Or is this intended to become an upgrade for the Cosmos Hub (which is a particular blockchain)?

I believe that the custom modules will eventually be submitted to the Cosmos sdk as an upgrade for the Cosmos Hub and other blockchains Cosmos network. @jazzy and @jackzampolin do you have any insight on this?

denalimarsh · 2019-06-05T19:03:49Z

Future requests for revisions should be directed to #51 and any outstanding comments from this PR will be addressed in #51 . This PR will be removed once the relevant revisions have been integrated in the completed unidirectional branch.

denalimarsh · 2019-07-10T07:11:14Z

Closing this as #51 contains the up-to-date version of the smart contracts which include any requested changes from this PR.

Oracle attestation handles

denalimarsh added 2 commits April 30, 2019 00:27

Safe lock/unlock functionality for testing unidirectional movement of…

e45143a

… funds from Ethereum to Cosmos

Reapplying existing module structure

d7366fd

zramsay requested review from sunnya97 and mossid May 16, 2019 21:58

cwgoes self-requested a review May 16, 2019 22:18

denalimarsh added 4 commits May 16, 2019 19:53

Updated naming conventions in Peggy smart contracts

0dcb471

Updated naming conventions on test suite to reflect smart contracts

9da21d6

Updated item deletion upon transfer of funds to item unlocking

1bd7453

Updated README to reflect changed naming conventions

4947e93

This was referenced May 20, 2019

what's the status with this repo? #48

Closed

Status of this project #45

Closed

How can I build the project? #39

Closed

Error: Cannot find module 'lodash' #41

Closed

zmanian assigned mossid and fedekunze May 20, 2019

denalimarsh added 3 commits May 21, 2019 00:34

Merge remote-tracking branch 'origin' into unidirectional

60c588b

Updated Project Specification with details, diagrams, and deployed Ro…

8e57270

…psten address

Updating markdown spacing

fc1ac51

fedekunze reviewed May 27, 2019

View reviewed changes

Fixed typo in package.json

9b3938c

cwgoes suggested changes May 29, 2019

View reviewed changes

denalimarsh added 2 commits May 30, 2019 00:53

Revisions

6a97c81

Specification narrowed to contextualization of Peggy

a118e50

denalimarsh mentioned this pull request Jun 4, 2019

Peggy smart contracts and test suite swishlabsco/cosmos-ethereum-bridge#13

Closed

musnit mentioned this pull request Jun 5, 2019

Fully functional unidirectional bridge #51

Merged

denalimarsh closed this Jul 10, 2019

jkilpatr pushed a commit that referenced this pull request Oct 16, 2020

Merge pull request #50 from althea-net/attestation_handlers

024bbb2

Oracle attestation handles

tac0turtle deleted the unidirectional branch March 11, 2021 09:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unidirectional ethereum-contracts #50

Unidirectional ethereum-contracts #50

denalimarsh commented Apr 30, 2019

cwgoes commented May 16, 2019

denalimarsh commented May 27, 2019

fedekunze commented May 27, 2019

fedekunze May 27, 2019

denalimarsh May 29, 2019

fedekunze May 29, 2019

denalimarsh May 30, 2019

fedekunze May 27, 2019

denalimarsh May 29, 2019

cwgoes left a comment

cwgoes May 29, 2019

denalimarsh May 30, 2019

cwgoes May 29, 2019

denalimarsh May 30, 2019

cwgoes May 30, 2019

cwgoes May 29, 2019

denalimarsh May 30, 2019

cwgoes May 29, 2019

denalimarsh May 30, 2019

denalimarsh commented Jun 5, 2019

denalimarsh commented Jul 10, 2019

Unidirectional ethereum-contracts #50

Unidirectional ethereum-contracts #50

Conversation

denalimarsh commented Apr 30, 2019

cwgoes commented May 16, 2019

denalimarsh commented May 27, 2019

fedekunze commented May 27, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cwgoes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

denalimarsh commented Jun 5, 2019

denalimarsh commented Jul 10, 2019