Relayer stopped automatically after throwing EOF error.Attached screenshot for reference.

Currently the testnet-contracts/scripts direcotry contains individual truffle exec scripts which enable smart contract interaction. Some limitations of using truffle exec include limited command line argument parsing, limited error messages, and a long execution time. Instead of being dependent on truffle-specific JavaScript scripts for contract interaction, we should build out a set of Golang scripts which use generated contract bindings to facilitate contract interaction. The Golang scripts will be accessible via either the existing ebcli or ebrelayer. This will concentrate all the smart contract interaction and allow us to easily expose the scripts through the planned JavaScript wrapper.

The project was started before various new SDK APIs and conventions emerged. The next phase should update the code to use these new APIs and conventions. Various small things can be changed to fit newer cosmos module conventions:

• the way keepers are stored in the ethereumBridgeApp struct
• use the new supply module
• Use new module generalization allows you to register the modules easily. eg: in the SDK simapp/app.go
• remove need for Genesis.go
• use param functionality for the consensusNeeded field
• can use new validator.IsBonded() in keeper.go
• further suggestions from https://github.com/cosmos/cosmos-sdk/blob/master/docs/modules/SPEC.md
• put querier into Keeper module
• return Events from handler appropriately based on new Events paradigm rather than Tags
• switch to go.mod
• use new account receiver in txs/relay.go
• update to latest version of sdk and remove dependency on https://github.com/swishlabsco/crypto
• change staking.Keeper to an interface that exposes only the methods used by this module
• can use new sdk.NewCoins() in parser.go
• add checks from #51 (comment)
• use module level cdc structure, ie: #51 (comment)

LICENSE?

In automatic claim processing the relayer is not able to detect the events and performs a succesfull transation.
Since i tried transferring the tokens from remix i didnt received any output from relayer but the transaction was successful but when i checked the receiver account there was no update in the account .

would be cheaper to use a proxy factory to deploy proxies to a cosmosERC20: https://gist.github.com/GNSPS/ba7b88565c947cfd781d44cf469c2ddb

When dynamic types like bytes are included in a log, it makes the length of the log data not a multiple of 32. For example, this is a log data for Lock(bytes to, uint64 amount, address token)(line break for every 32 bytes == 1 word).

0000000000000000000000000000000000000000000000000000000000000060
0000000000000000000000000000000000000000000000000000000000002710
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000003
686868

The first word contains the relative position of the first element(hex 60 == dec 96). The word in that position contains the length of the bytes. The 3-byte data 686868 follows it.

It makes the parse_log in ethabi package not works. (ethabi/src/util.rs line 7-9)

if data.len() % 32 != 0 {
    return Err(ErrorKind::InvalidData.into());
}

To solve this problem, we have to change every bytes in solidity files into bytes32. On the frontend side, we can either 1. hash the input data to make it bytes32 or 2. accept bytes only whose length is less than 32.

So the api should be modified as:

lock(bytes32 to, uint64 value, address token) external payable returns (bool);
event Lock(bytes32 to, uint64 value, address token);

unlock(address[2] addressArg, uint64 value, bytes32 chain, uint16[] idxs, uint8[] v, bytes32[] r, bytes32[] s) external returns (bool)

unlock also has to take bytes32 in favor of #32

Add more linters to golangci: https://github.com/cosmos/cosmos-sdk/blob/master/.golangci.yml

The signer component holds a Secpk key that is registered with the pegzone contract on Ethereum.
It listens for RedeemTx events from the pegzone and then signs those and posts a SignTx back to the pegzone.

@ethanfrey @mossid @spacejam

I am having a testuser i want to make him validator.
I have used the command mentioned in Image-1.The command is showing the output successfully but when i am checking the staking validators its showing me the default one provided at time of creating the genensis.

The Relayer should enforce a finality threshold of n blocks so that witnessed events are probabilistically deterministic. The proposed implementation is a finality queue which enforces a 6 block finality threshold on witnessed events before allowing validators to sign them. This event persister can be expanded to a Relayer service which scans the blockchain for missed transactions upon initialization.

Thanks for creating this! I like the design you guys chose. Is there a finality check in the Relayer code? Relayer should have some finalityBound parameter so that it waits finalityBound number of blocks after seeing an event before creating an EthBridgeClaims. This mitigates risk that Etheruem re-orgs from causing peggy state to be invalid.

Originally posted by @AdityaSripal in #51 (comment)

Earlier we had to define the validator separately with the commission rates and all other characteristics.In the present version there is no mention of Validator credentials.
I think this might be the reason there is issue with the relayer and smart contract connection.
Can anybody please put some light on this..

Earlier peggy

ebcli tx staking create-validator
--amount=100000000stake
--pubkey=$(ebd tendermint show-validator)
--moniker="test_moniker"
--chain-id=testing
--commission-rate="0.10"
--commission-max-rate="0.20"
--commission-max-change-rate="0.01"
--min-self-delegation="1"
--gas=200000
--gas-prices="0.001stake"
--from=validator

Then wait 10 seconds then confirm your validator was created correctly, and has become Bonded status

ebcli query staking validators --trust-node

in present peggy this has been removed ..why?????

On contract, each Item's id is currently a hash containing: sender's contract address on the Ethereum network, specified recipient address on the Bridge network, the token type's deployed address on the Ethereum network, the amount, and the current nonce. Changing Item id to just the nonce maintains security and simplifies the smart contracts. The Relayer's LockEvent struct must also be updated in order to integrate these changes.

Proposed change from:

If the nonce is unique, why can't this mapping just use the nonce as the key?

Originally posted by @AdityaSripal in https://github.com/_render_node/MDExOlB1bGxSZXF1ZXN0Mjg1NTA0Nzkz/timeline/more_items

why call burn function in comsosERC20.sol from lock function in peggy.sol ?

@denalimarsh can you update circleci to do truffle stuff/some tests as well

Originally posted by @musnit in #63 (comment)

We need to natively build in a mechanism to upgrade the peggy contracts on Ethereum in order to add features in the future (and potentially but really really hopefully not solve bug fixes). Normally building Ethereum upgradeable contracts is a weird concept because its often unclear who should have the right to upgrade a Dapp, but in the case of Peggy, it seems that the current validator set should be able to upgrade it.

Some resources on upgradable contracts: https://sunnya97.gitbooks.io/a-beginner-s-guide-to-ethereum-and-dapp-developme/content/upgradable-contracts.html

Building upgradeable contracts is not easy and I don't there are that many solidity devs with experience building them. You'd have to complicated delegatecalls and stuff like that and we'd like to avoid a Parity bug like situation

The rest client interface requires a lot of paramaters to query a prophecy, so means an annoying time making the request:

	r.HandleFunc(fmt.Sprintf("/%s/prophecies/{%s}/{%s}/{%s}/{%s}/{%s}/{%s}", storeName, restEthereumChainID, restBridgeContract, restNonce, restSymbol, restTokenContract, restEthereumSender), getProphecyHandler(cliCtx, storeName)).Methods("GET")

This could be improved by adding an id to the prophecy object and allow for querying just by id. This probably makes sense, though should be thought through more - there are a bunch of implications of adding ids, like:

• more space used
• doesn't improve UX for end users at all really, only devEX for developers building ontop of peggy, which is a minor efficiency difference anyway. End users will likely eventually interact with these systems through some frontend/UI/dapp, where the chainid/contract/nonce/etc will likely be either hardcoded, or selectable in a dropdown, or remembered from previous usage.
• having an id and endpoint based on id means that prophecies can no longer be retrieved easily by deterministically working out the url based on what original request they got triggered by, and there are likely some consumers based that need this characteristic. we can of course still leave this compound-key endpoint in, in addition to adding a single-key id endpoint, so that those needs are still met
• clients/fat web apps that are built in future consuming this UI now also may need to keep track of ids, and the id will be generated server(blockchain) side and so they need to get it from the server
• most transactions/requests will likely come in asynchronously, where it is not possible to return the id in that request, so consumers will need to do a second query later on, or wait for transaction confirmation until they get the id back and know what it is.

anyway, as mentioned, we could also have both query endpoints in so may make sense to go ahead with adding ids

Additional tests for the x/ethbridge/types/msgs.go file testing ValidateBasic would be valuable, so should be added.

Also, refactoring tests out as in #51 (comment) should be done.

Note - Taken from: #51 (comment)

The Ethereum pegzone contract has a function that takes amount int64, denom string, signatures []signatures. Signatures is a solidity struct that encapsulates the components of a signature. It is used by the smart contract to authenticate the rest of the data.

The smart contract hashes amount and denom and checks whether all signatures come from a validator and wether the sum of signatures accounts for >2/3 of the voting power.

type Signatures struct {
    ...
}

@mossid @fedekunze @sunnya97

This issue was created due a conversation over in swishlabsco/peggy: swishlabsco#4 (comment)

TokenContractAddress may also be needed in the Denom in order to guarantee coin uniqueness (see comment).

The Relayer as a validator component rather than a trustless separate component.

• No need for relayer signing or trust infrastructure in EthBridge.
• No need for a relayer cryptoincentive model.
• No need to consider relayer/validator trust in any way. Only Eth finality must be considered.

Disadvantages of all validators also being relayers

• validators must now have and configure a trusted Eth full node
• validators must now maintain the uptime of that full node in addition to the validator. Although it won't really matter that much if the full node goes down for short periods.
• If less than 66% of the validators have a working Eth full node configured the bridge will cease to function.

I'm curious for thoughts/feedback on this. It seems to me that you could realize a fully working system with a much more anaemic relayer and then separate it out later. Rather than tackling the hard work up front. Sure the validator operators have to do more work, but since most peg zones have the bridge as a very core component I don't think that's a huge problem.

use !IsZeroAddress(msg.TokenContractAddress)

Originally posted by @fedekunze in #68

The typing difference is preventing project wide utility functions from providing value to both the Relayer service and the modules. In order to resolve this issue, the Relayer should be refactored to use custom type EthereumAddress.

The relayer component listens to events from the pegzone and forwards data from the pegzone to Ethereum via contract calls.

The relayer can be run by anyone and is trustless.

@spacejam @mossid

the func in CosmosERC20.sol doesn't work ?

function mint(address to, uint amount) public onlyByController() returns (bool success) {
balances[to] = balances[to].add(amount);
_totalSupply = _totalSupply.add(amount);
Mint(to, amount);
return true;
}

Should emit an unlock event when a WithdrawTx has been successfully relayed to the EVM chain so that it can be witnessed by the witnesses and thus we can know when it is safe to prune the signed WithdrawTxs from the state of the Peg Zone.

Description: The Relayer test suite should be more robust and expansive. Any broken/pending code related to the Relayer test suite has been removed and will be reintegrated in another PR once complete.

Originally posted by @musnit in https://github.com/_render_node/MDE3OlB1bGxSZXF1ZXN0UmV2aWV3MjU0MjU1ODA1/pull_request_reviews/more_threads

"I think it's fine if we create a github issue for doing a proper relayer test suite, and then just clean this up, remove broken/pending code, and put a reference to that Github issue."

The current module only mints ETH representative tokens on the cosmos chain. It should be enhanced to consider the ERC-20 token sent and possibly mint tokens on the cosmos chain to represent arbitrary ERC-20 tokens.

The module also does not track the source chain and contract which the message came from, which may be useful for ensuring nonfungibility of tokens minted from different source bridge contracts for security benefits.

Steps:

1. Extend module.go to implement the AppModuleSimulation interface and create the simulation/ folder with the decoder.go (+ _test.go), genesis.go, operations.go (see x/staking/simulation for reference)

2. Create the app simulation manager (you can use the app/app.go on Gaia for reference).

3. Add test-sim-... cmds to the Makefile (use SDK as reference)

4. Create sim_test.go(simulation tests for the app). I'd recommend you to use this Gaia PR as a reference since it simplifies the creation process of those tests.

The witness component is responsible for following the Ethereum consensus. It witnesses events that happen on the Ethereum blockchain after a certain number of blocks and witnessing an event makes it final. The witness component submits a WitnessTx to the pegzone with the event data.

@spacejam @mossid

Consumers may want to iterate over the prophecies in the database. Currently, only APIs for querying a single prophecy exist. It could be useful to add an iterator and API to get multiple/all.

The proper method of sending ERC20 tokens to a contract is to use the approve/transferFrom paradigm as due to the design of the current ERC20 standard, if an external account transfers to a contract directly, the contract does not get notified that it was sent tokens and thus has no way of knowing which address sent it tokens. (Note: ERC223 is a proposed solution to this problem that also allows transfers to trigger a function on the recieving contract as well as include some data, however 223 is not officially approved nor widely adopted, and I also have some issues with its design).

Inevitably, people are going to accidentally send ERC20 tokens to our peg zone contract (which will be silly because there's no way of attaching destination data to this, but still, it's going to happen). I've added to the Cosmos ERC20 contracts that it reverts if someone tries to do this but I can't stop people from sending native Ethereum ERC20s to the contract. But I think we can actually solve this with the following mechanism:

While it does not inform a receiving contract of a transfer, the ERC20 standard does however include an event called Transfer that adds to the Logs whenever a transfer happens. We can have witnesses listen for all Transfer events in which the _to address is the peggy contract. They can then log this to the Peg Zone and the signers can sign a new Ethereum transaction that sends the funds back to the _from address from the Event. (You can actually combine these into one step because the witnesses are the signers). Once the returnTx has enough signatures, it can be relayed back to Ethereum to return the locked funds.

Hello.

I am trying to use ebcli to burn tokens that have been or will be unlocked onto Ethereum, with the following command:

ebcli tx ethbridge burn cosmos1py2hyelc8lwqfm44wtjdfe3gq6vhlrykhaw4gz 0xBe4680d29AC7129D0Db45E4017DD146579a6C931 1000000000000000000blz --token-contract-address=0x75E6f42Daba0e300287f14e99086104820582D34 --ethereum-chain-id=3 --from=validator --chain-id=mychain --yes

Unfortunately, and rather non-deterministically, this command will sometimes (it sometimes succeeds too!) fail with the following error:

failed to get from fields: couldn't create db: Error initializing DB: resource temporarily unavailable

I see this error alot across the board, and seem to recall seeing it being output from the ebrelayer as well. It seems to be a cause of a large number of problems, as we will sometimes be able to do tests and sometimes, not.

Any thoughts here? Which "DB" is this? I suspect it is the blockchain's database, but am unsure.

I get this error quite a bit if I want to run a relayer but am already running the REST-server, as follows:

ebcli rest-server --laddr=tcp:// --chain-id=<my_chain_id>

If I am running the REST-server and get that error when running the relayer, I am forced to kill the REST-server, to get further.

Please share your thoughts.

Hi,
I see there is no new update for 9 months. Will it be continue in near future ?

Support NFT's (ERC721) by deploying a NFT contract which handles all NFT's that are from external chains and another which can hold any NFT and send it to cosmos chains.

Cosmos NFT uuid
When sending from NFT contract to external cosmos chain, NFT uuid should perhaps be
[chainId][nftAdress][orginalUUID] -> 8B + 32B + 32B = 72 bytes UUID

When receiving external NFT's, for compatibility take sha3 as uint256 of "cosmos NFT uuid", this is applicable when deploying a peggy-erc721-receiver in a ethermint zone

Otherwise cosmos NFT's should be identified by their full 72bytes UUID.

Metadata in ethereum mainnet could be extended with fields:
function getSourceChainId(uint index) returns uint8
function getSourceAdress(uint index) returns bytes32
function getSourceTokenId(uint index) returns uint256

See ERC721 EIP:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md

Other solution would be to make a ERC721 contract for every received NFT source

I know this project came along from etgate and I didn't have luck to build a working binary for etgate yet. Is this project able to be built and run? Thanks.

Code should adhere to Uber's go style guide. Some notable sections from the style guide include:

• Start Enums at One
• Error Types
• Group Similar Declarations
• Import Group Ordering
• Function Grouping and Ordering
• Prefix Unexported Globals with _
• Initializing Struct References
• Format Strings outside Printf
• Patterns: Test Tables

It's unclear what the status of this repo is. I was following that the concept of peg started with other ideas first but culminated in this repository. It seems pretty central for the cosmos project, but it hasn't been updated in a while.

I was hoping to try to create a proof of concept that I can transfer tokens back and forth between a vanilla Ethereum chain and a tendermint backed application using this, but I can't really figure out how to run this or what's left to do before it's in a testable state. Can someone elaborate?

truffle test --network ganache

Using network 'ganache'.

Error: Cannot find module 'lodash'
at Function.Module._resolveFilename (module.js:555:15)
at Function.Module._load (module.js:482:25)
at Module.require (module.js:604:17)
at require (internal/module.js:11:18)
at Object. (/home/wade.lee/goWorkProject/src/github.com/cosmos/peggy/ethereum-contracts/test/utils.js:3:9)
at Module._compile (module.js:660:30)
at Object.Module._extensions..js (module.js:671:10)
at Module.load (module.js:573:32)
at tryModuleLoad (module.js:513:12)
at Function.Module._load (module.js:505:3)
at Module.require (module.js:604:17)
at require (internal/module.js:11:18)
at Object. (/home/wade.lee/goWorkProject/src/github.com/cosmos/peggy/ethereum-contracts/test/cosmosERC20.js:4:15)
at Module._compile (module.js:660:30)
at Object.Module._extensions..js (module.js:671:10)
at Module.load (module.js:573:32)
at tryModuleLoad (module.js:513:12)
at Function.Module._load (module.js:505:3)
at Module.require (module.js:604:17)
at require (internal/module.js:11:18)
at /usr/local/lib/node_modules/truffle/node_modules/mocha/lib/mocha.js:231:27
at Array.forEach ()
at Mocha.loadFiles (/usr/local/lib/node_modules/truffle/node_modules/mocha/lib/mocha.js:228:14)
at Mocha.run (/usr/local/lib/node_modules/truffle/node_modules/mocha/lib/mocha.js:514:10)
at /usr/local/lib/node_modules/truffle/build/webpack:/~/truffle-core/lib/test.js:125:1
at
at process._tickCallback (internal/process/next_tick.js:160:7)

I noticed some modules are missing on the app.go. I wanted to start a discussion about the available modules that the peg zone should or must have.

Must have:

• x/evidence: evidence handling was migrated from x/slashing to the new evidence module
• x/slashing: for downtime and double sign slashing
• x/upgrade: reduces the upgrading time from software updates (i.e new version releases) to only a few minutes. Integrates upgrade proposals to ease the coordination process on versioning, exact time/height of the upgrade.
• x/gov: for param change, text, community spend and upgrade proposals, etc.
• x/distribution: in protocol staking reward and fee distribution mechanism for validators and delegators.
• x/crisis: submit a tx to halt the chain in case an invariant check has been found.
• x/mint: Inflation rates for the coins (eg: staking coin).

Other modules (TBD):

• x/ibc: IBC protocol implementation

which modules should we modify or pay attention to bring Peggy to the production level?
why do you mention that Peggy is not of production level, is it due to the lack of security or efficiency?
Basically, what are the functionalities that the Peggy currently lack and make it unsuitable for the production?

Hi, there are some problems when I "cd to cmd/etgate and go build". Can I get some instruction or help? thanks a lot for any response!

when my input is like:
cd $GOPATH/src/github.com/cosmos/peggy/cmd/etgate/
go build
the result is like:

main.go:14:5: local import "./commands" in non-local package
gate.go:36:5: local import "../../commands" in non-local package
gate.go:37:5: local import "../../contracts" in non-local package
gate.go:35:5: local import "../../plugins/etgate" in non-local package
gate.go:38:5: local import "../../plugins/etgate/abi" in non-local package

or when my input is like
go build main.go

the result is like:

# github.com/tendermint/tendermint/rpc/client
../../../../tendermint/tendermint/rpc/client/httpclient.go:244:12: query.String undefined (type pubsub.Query has no field or method String)
../../../../tendermint/tendermint/rpc/client/httpclient.go:261:12: query.String undefined (type pubsub.Query has no field or method String)
# _/root/workspace/src/github.com/cosmos/peggy/plugins/etgate
../../plugins/etgate/etgate.go:73:16: undefined: "github.com/tendermint/abci/types".Result
../../plugins/etgate/etgate.go:88:42: undefined: "github.com/tendermint/abci/types".Result
../../plugins/etgate/etgate.go:109:38: undefined: "github.com/tendermint/abci/types".Result
../../plugins/etgate/etgate.go:122:39: undefined: "github.com/tendermint/abci/types".Result
../../plugins/etgate/etgate.go:134:34: undefined: "github.com/tendermint/abci/types".CodeType
../../plugins/etgate/etgate.go:135:33: undefined: "github.com/tendermint/abci/types".CodeType
../../plugins/etgate/etgate.go:136:32: undefined: "github.com/tendermint/abci/types".CodeType
../../plugins/etgate/etgate.go:137:31: undefined: "github.com/tendermint/abci/types".CodeType
../../plugins/etgate/etgate.go:138:33: undefined: "github.com/tendermint/abci/types".CodeType
../../plugins/etgate/etgate.go:139:35: undefined: "github.com/tendermint/abci/types".CodeType

This issue is for the reintegration of OpenZeppelin's ECDSA library, including any minor updates to the ebrelayer/contract test suite if required.

Background:
Valset's signature verification has been updated in #77 due to issues with OpenZeppelin's ECDSA library. While the library correctly prefixes and validates messages signed off-chain with web3.eth.sign() in the contract test suite, it does not correctly validate messages signed by validators running the ebrelayer. We can confirm that validator signatures are correct using cmd/ebrelayer/txs/utils.go's verifySignature(), and are also working with ecrecover(...) on-chain inside Valset.sol outside of OpenZeppelin's ECDSA library.

Created due to:
create issue

Originally posted by @fedekunze in #77

As further described in #77, ethereum and cosmos relayer could be refactored into a unified relayer which only has 1 ebrelayer init for ease of use. The unified relayer could share a logger, event data, init config information, and validator account information through the use of goroutines and environment variables.

For the WithdrawTx that sends funds from pegzone --> Ethereum there are 2 fees that need to be paid: the ones from the transaction in the zone itself (in Photons) and the ones of the Ethereum transaction. Technically the Relayer is the one that pays the fee in ETH, since it's the one who sends the parsed transaction to native Ethereum, while the address that submits the WithdrawTx is the one that pays the first fee in Photons.

To avoid having the Relayer pay the Ethereum fees, I suggest that the user from the Pegzone pay both fees. For this one approach is to split the total Fee in two (x% and 100 - x%) according to a certain default arbitrary percentage (which can be updated by the user) or otherwise set the amount of each fee manually using the user's input.

I tried running the ropsten netwrok integration for automatic relaying process but it seems it is not working properly.The relayer is not able to connect to the deployed address showing web socket issue.I have attached screenshot for the reference

The pegzone ties all other components (Witness, Relayer and Signer) together. It defines the format for WitnessTx, WithdrawTx, SignTx and SendTx.

The WitnessTx is send by the Witness component. It results in the pegzone writing the event (usually a deposit into the Ethereum smart contract) into its state. There is aggregates all WitnessTxs for a given event and credits a user account once >2/3 of validators have witnessed an event.

type WitnessTx struct {
    ethEvent EthEvent // encapsulates amount, token and destination address
    signature Signature // has to be a signature from a key in the validator set
}

type EthEvent struct {
    destination []byte // pegzone address
    coin Coin // contains denom and amount of the token to be send

The WithdrawTx is sent by a user to send money from the pegzone to Ethereum. The pegzone checks whether the user has the correct token balances and then deducts them from the user account.

type WithdrawTx struct {
    destination []byte // Ethereum address of destinatary
    coin Coin // contains denom and amount of the token to be send
    signature Signature // a signature that authorises this transaction
}

type WithdrawData struct {
     SignedWithdraw []SignTx	 // Accumulates `SignTx`s until it reaches +2/3 of total power
}

The SignTx is sent by the Signer component.

type SignTx struct {
    signatureBytes []bytes // signature bytes over the concatenation of the top three fields of ReedemTx
    signature Signature // signature that authorises this transaction is coming from a validator
}

@ethanfrey @spacejam @mossid @sunnya97 @fedekunze
The SendTx is used to send tokens between user account on the pegzone.