Update Developer Guide #37

johnwhitton · 2022-05-25T22:16:17Z

No description provided.

…d questions

polymorpher · 2022-05-26T03:12:53Z

docs/README.md

+# Overview
+
+The current state of the project is that we are testing using a Harmony Local Node and brdiging to Ropsten. For the client we will use the CLI and moving forward will use the new UI
+* DAG genertion : Takes several hours to run Ganesha has a machine to do this and shares the latest DAG info from Ropsten using [google drive](https://drive.google.com/file/d/1FqLCO5oc1xDYNMuub7xAqnb6kfohdf-U/view?usp=sharing). The epoch logic is the block Number divided by 30,000 so current Ropsten EPOCH is block 12280236 / 30000 = 409 which is the DAG info shared above. **Moving forward we need to update DAG information for every new EPOCH**


Each epoch should have 32768 blocks https://docs.harmony.one/home/network/validators/definitions/epoch-transition

polymorpher · 2022-05-26T03:18:31Z

docs/README.md

+
+The current state of the project is that we are testing using a Harmony Local Node and brdiging to Ropsten. For the client we will use the CLI and moving forward will use the new UI
+* DAG genertion : Takes several hours to run Ganesha has a machine to do this and shares the latest DAG info from Ropsten using [google drive](https://drive.google.com/file/d/1FqLCO5oc1xDYNMuub7xAqnb6kfohdf-U/view?usp=sharing). The epoch logic is the block Number divided by 30,000 so current Ropsten EPOCH is block 12280236 / 30000 = 409 which is the DAG info shared above. **Moving forward we need to update DAG information for every new EPOCH**
+* CLI Relayer : Relays the blocks, this is initially written in javascript as a Proof of concept and may be implemented in other languages moving forward. **Once the Relayer has begun we need to continually relay each block**


Might be worthwhile discussing the differences in frequency and behaviors of how block headers are relayed between Ethereum and Harmony

polymorpher · 2022-05-26T03:28:55Z

docs/README.md

+The current state of the project is that we are testing using a Harmony Local Node and brdiging to Ropsten. For the client we will use the CLI and moving forward will use the new UI
+* DAG genertion : Takes several hours to run Ganesha has a machine to do this and shares the latest DAG info from Ropsten using [google drive](https://drive.google.com/file/d/1FqLCO5oc1xDYNMuub7xAqnb6kfohdf-U/view?usp=sharing). The epoch logic is the block Number divided by 30,000 so current Ropsten EPOCH is block 12280236 / 30000 = 409 which is the DAG info shared above. **Moving forward we need to update DAG information for every new EPOCH**
+* CLI Relayer : Relays the blocks, this is initially written in javascript as a Proof of concept and may be implemented in other languages moving forward. **Once the Relayer has begun we need to continually relay each block**
+* Client: The client is used to Process transactions this is done by locking the Token using the TokenLocker.sol contract (e.g. TokenLockerOnEth.Sol AND TokenLockerOnHarmony.sol)


Is this referring to Ethereum and Harmony light clients? I think they are for adding and verifying block headers from the other side. Token lockers are for managing tokens and verifying transactions and releasing the tokens after a bridge transaction is verified.

polymorpher · 2022-05-26T03:31:41Z

docs/README.md

+* Client: The client is used to Process transactions this is done by locking the Token using the TokenLocker.sol contract (e.g. TokenLockerOnEth.Sol AND TokenLockerOnHarmony.sol)
+Currently only ERC20 are supported. Moving forward ERC721 and ERC1155 as well as operations on smart contracts will also be supported. For now all client transactions will be done using the CLI. Moving forward  the current bridge (bridge.harmony.one) will be migrated to https://bridge-validator-1.web.app/ and jenya also built a fresh frontend for upcoming trustless bridge: https://github.com/harmony-one/horizon-trustless-frontend
+but most likely, we will stick to the first one.
+* Harmony Node: we use a [harmony local node](https://github.com/harmony-one/harmony#dev-docker-image) this can be run via docker. **There is a pull request which needs to be pushed to Harmony Testnet to enable the bridging functionality. [we need this PR to be pushed to testnet (should be done by May 27th, 2022)](https://github.com/harmony-one/harmony/pull/3872)**


Why is this PR needed? Is it not sufficient to have the block header submitters (relays) to compute the MMR?

polymorpher · 2022-05-26T03:37:13Z

docs/README.md

+Currently only ERC20 are supported. Moving forward ERC721 and ERC1155 as well as operations on smart contracts will also be supported. For now all client transactions will be done using the CLI. Moving forward  the current bridge (bridge.harmony.one) will be migrated to https://bridge-validator-1.web.app/ and jenya also built a fresh frontend for upcoming trustless bridge: https://github.com/harmony-one/horizon-trustless-frontend
+but most likely, we will stick to the first one.
+* Harmony Node: we use a [harmony local node](https://github.com/harmony-one/harmony#dev-docker-image) this can be run via docker. **There is a pull request which needs to be pushed to Harmony Testnet to enable the bridging functionality. [we need this PR to be pushed to testnet (should be done by May 27th, 2022)](https://github.com/harmony-one/harmony/pull/3872)**
+* For fully trustless bridge we need the bls signature verification precompile to be available on ethereum [eip-2537](https://eips.ethereum.org/EIPS/eip-2537), however this won't be a blocker, as we can initially do permissioned relayers, later adopt optimistic approach, etc. there are many fallback plans for this.


Can this be clarified in more detail? Where is BLS signature verification needed, and why isn't there any alternative? What are the optimistic approach and fallback options?

polymorpher · 2022-05-26T03:38:42Z

docs/README.md

+* DAG genertion : Takes several hours to run Ganesha has a machine to do this and shares the latest DAG info from Ropsten using [google drive](https://drive.google.com/file/d/1FqLCO5oc1xDYNMuub7xAqnb6kfohdf-U/view?usp=sharing). The epoch logic is the block Number divided by 30,000 so current Ropsten EPOCH is block 12280236 / 30000 = 409 which is the DAG info shared above. **Moving forward we need to update DAG information for every new EPOCH**
+* CLI Relayer : Relays the blocks, this is initially written in javascript as a Proof of concept and may be implemented in other languages moving forward. **Once the Relayer has begun we need to continually relay each block**
+* Client: The client is used to Process transactions this is done by locking the Token using the TokenLocker.sol contract (e.g. TokenLockerOnEth.Sol AND TokenLockerOnHarmony.sol)
+Currently only ERC20 are supported. Moving forward ERC721 and ERC1155 as well as operations on smart contracts will also be supported. For now all client transactions will be done using the CLI. Moving forward  the current bridge (bridge.harmony.one) will be migrated to https://bridge-validator-1.web.app/ and jenya also built a fresh frontend for upcoming trustless bridge: https://github.com/harmony-one/horizon-trustless-frontend


What are the paths to support ERC721 and ERC1155? It would be nice to have some clarifications or pointers to technical components required and TODO lists

polymorpher · 2022-05-26T03:39:15Z

docs/README.md

+# Overview
+
+The current state of the project is that we are testing using a Harmony Local Node and brdiging to Ropsten. For the client we will use the CLI and moving forward will use the new UI
+* DAG genertion : Takes several hours to run Ganesha has a machine to do this and shares the latest DAG info from Ropsten using [google drive](https://drive.google.com/file/d/1FqLCO5oc1xDYNMuub7xAqnb6kfohdf-U/view?usp=sharing). The epoch logic is the block Number divided by 30,000 so current Ropsten EPOCH is block 12280236 / 30000 = 409 which is the DAG info shared above. **Moving forward we need to update DAG information for every new EPOCH**


What are the DAGs for and how is it generated?

polymorpher · 2022-05-26T03:44:26Z

docs/README.md

+
+**Migration Strategy**
+* Smart Contract use Hardhat with Typescript and ethers(instead of web3)
+  * Replace all web3 with ethers


Are other developers comfortable with this?

polymorpher · 2022-05-26T03:45:57Z

docs/README.md

+**Migration Strategy**
+* Smart Contract use Hardhat with Typescript and ethers(instead of web3)
+  * Replace all web3 with ethers
+  * replace all js files with typescript


Similarly for this - let's make sure it doesn't create too much extra work since we need to launch this fast. Can this be postponed for later?

polymorpher · 2022-05-26T03:49:25Z

docs/README.md

+* src/cli: (migrated from cli)
+* src/(elc, eprover, eth2hmy-relay): migrated from tools(elc, eprover, eth2hmy-relay)
+
+**RollOut Strategy**


It would be very helpful to have more unit tests, and comments explaining what each component (and unit test) is doing. Right now it is not apparent that each unit component is functioning as intended, what the corner cases are, what the potential attack vectors are, and how they are defended (through the bridging mechanism). It would be nice to have the unit tests illustrating those

polymorpher · 2022-05-26T03:55:36Z

docs/README.md

+* DAG genertion : Takes several hours to run Ganesha has a machine to do this and shares the latest DAG info from Ropsten using [google drive](https://drive.google.com/file/d/1FqLCO5oc1xDYNMuub7xAqnb6kfohdf-U/view?usp=sharing). The epoch logic is the block Number divided by 30,000 so current Ropsten EPOCH is block 12280236 / 30000 = 409 which is the DAG info shared above. **Moving forward we need to update DAG information for every new EPOCH**
+* CLI Relayer : Relays the blocks, this is initially written in javascript as a Proof of concept and may be implemented in other languages moving forward. **Once the Relayer has begun we need to continually relay each block**
+* Client: The client is used to Process transactions this is done by locking the Token using the TokenLocker.sol contract (e.g. TokenLockerOnEth.Sol AND TokenLockerOnHarmony.sol)
+Currently only ERC20 are supported. Moving forward ERC721 and ERC1155 as well as operations on smart contracts will also be supported. For now all client transactions will be done using the CLI. Moving forward  the current bridge (bridge.harmony.one) will be migrated to https://bridge-validator-1.web.app/ and jenya also built a fresh frontend for upcoming trustless bridge: https://github.com/harmony-one/horizon-trustless-frontend


It seems the frontend implementation contains only a basic user interface, and does not have the majority of the necessary frontend components (APIs, services, state and session management, error handling, UI usage of APIs, and many others). I think the documentation we put here should reflect some of the details and the state of the frontend, otherwise it may give developers, users, and partners an inaccurate impression of the state of completion

polymorpher · 2022-05-26T03:56:15Z

docs/README.md

+* Complete End To End Testing (using CLI)
+* Write Smart Contract Tests (will use hardhat)
+* Update Smart Contract Documentation and README.md
+* Integrate with Front END UI


As commented above - it seems some substantial frontend implementation work needs to be done before integration could take place

polymorpher · 2022-05-26T04:00:22Z

docs/README.md

+* Write Smart Contract Tests (will use hardhat)
+* Update Smart Contract Documentation and README.md
+* Integrate with Front END UI
+* Onboard Production Validators (15 Validators to relay blocks - incentives tbd)


Non-validators can also relay blocks as long as they have access to a valid RPC node. Have we decided on the criteria of inclusion for the initial permissioned set of relayers? Many of them would be submitting redundant block headers and epochs - what are the top 3 things we want to achieve through this initial set of relayers, and what is the roadmap for transitioning into a permissionless set?

polymorpher · 2022-05-26T04:01:45Z

package.json

@@ -4,7 +4,8 @@
  "description": "Harmony soccerplayers.app",
  "main": "truffle.js",
  "scripts": {
-    "libInit": "tar -zxf ethereumjs-ethash-dist.tar.gz -C node_modules/@ethereumjs/ethash"
+    "libInit": "tar -zxf ethereumjs-ethash-dist.tar.gz -C node_modules/@ethereumjs/ethash",


What is this? Where does the .tar.gz package come from and how do relayers and developers verify they are trustworthy?

polymorpher · 2022-05-26T04:03:44Z

hardhat.config.js

@@ -8,6 +8,7 @@ require('@openzeppelin/hardhat-upgrades');
 */

 const HARMONY_PRIVATE_KEY = process.env.PRIVATE_KEY;
+const PROJECT_ID = process.env.INFURA_PROJECT_ID


Infura sometimes goes down for Ethereum testnets - I suggest we allow freeform provider URLs (so people can use AlchemyAPI and others)

polymorpher · 2022-05-26T06:43:32Z

docs/README.md

+
+* Deployer Address : 0x8875fc2A47E35ACD1784bB5f58f563dFE86A8451
+* Infura Project: 32cb9c57bfe447a99ea34e30195b2d10
+* KOVAN ERC20 Contract: [0xc90a6555CaD53a9D85a80052Fe2926E21608CF41](https://kovan.etherscan.io/address/0xc90a6555cad53a9d85a80052fe2926e21608cf41)


What is this contract for? Any testing facilities on the contract?

polymorpher · 2022-05-26T07:01:07Z

docs/README.md

+
+## Creating the DAG Merkle Tree
+
+DAG genertion takes several hours to run Ganesha has a machine to do this and shares the latest DAG info from Ropsten using [google drive](https://drive.google.com/file/d/1FqLCO5oc1xDYNMuub7xAqnb6kfohdf-U/view?usp=sharing). The epoch logic is the block Number divided by 30,000 so current Ropsten EPOCH is block 12280236 / 30000 = 409 which is the DAG info shared above.


The code looks like something that can be parallelized and made efficient. What exactly is DAG and what is the purpose of generating all of them? Why is it aligned to epoch numbers? I think these questions should be answered before discussing how DAG is generated and the relevant commands

polymorpher · 2022-05-26T07:04:39Z

docs/README.md

+Following is an overview of the contracts used in the bridge and which chain they should be deployed on. *Note: her we only focus on the contracts deployed the imported contracts are not covered*
+
+**Ethereum (Kovan)**
+* HarmonyLightClient.sol : stores all blockheaders which are used for verification.


Harmony block headers - I think it would be informative to document the differences compared to Ethereum block headers, and how the light clients act differently (frequency and nature of updates, cost considerations, etc.)

polymorpher · 2022-05-26T07:05:20Z

docs/README.md

+
+**Ethereum (Kovan)**
+* HarmonyLightClient.sol : stores all blockheaders which are used for verification.
+* TokenLockerOnEthereum.sol : Tracks tokens locked which are then minted by the bridge


Responsible for proof submission (i.e. execution of releasing tokens) as well

polymorpher · 2022-05-26T07:05:37Z

docs/README.md

+* TokenLockerOnEthereum.sol : Tracks tokens locked which are then minted by the bridge
+* FaucetToken.sol : Token created on Ethereum which will be bridged to Harmony (Testing Only)
+
+**Harmony (Localnet)**


Same as above

polymorpher · 2022-05-26T07:06:45Z

docs/README.md

+
+There are also two scripts available [deploy_eth_side.js](https://github.com/johnwhitton/horizon/blob/main/scripts/deploy_eth_side.js) and [deploy_hmy_side.js](https://github.com/johnwhitton/horizon/blob/main/scripts/deploy_hmy_side.js)
+
+**Questions**


Move to separate documents / discussion groups?

polymorpher · 2022-05-26T07:06:57Z

docs/README.md

+node index.js dagProve blockProof --block 11266784 --url https://ropsten.infura.io/v3/<project-id>
+```
+
+**Questions**


Move elsewhere?

polymorpher · 2022-05-26T07:12:25Z

docs/README.md

+Also [end2end.js](https://github.com/johnwhitton/horizon/blob/main/scripts/end2end.js) which does not have any code in it.
+
+**Original Documentation**
+Original documentation for the CLI contains [Bridge CLI](https://github.com/johnwhitton/horizon/tree/main/cli#bridge-cli), [Ethereum Receipt Prove CLI](https://github.com/johnwhitton/horizon/tree/main/cli#ethereum-receipt-prove-cli) and [Ethereum Receipt Verifier CLI](https://github.com/johnwhitton/horizon/tree/main/cli#ethereum-receipt-verifier-cli).


Can all links point to files in the original repository and made permalink (so they don't change across versions?)

polymorpher · 2022-05-26T07:16:06Z

docs/README.md

+7. `node index.js Bridge crossBack` cross transfer HRC20 from harmony back to ethereum.
+
+There are also two scripts written to facilitate testing. 
+1. [test.js](https://github.com/johnwhitton/horizon/blob/main/scripts/test.js)


This seems to be just a few unit tests with some utility functions

polymorpher · 2022-05-26T07:17:22Z

docs/README.md

+
+There are also two scripts written to facilitate testing. 
+1. [test.js](https://github.com/johnwhitton/horizon/blob/main/scripts/test.js)
+2. [newtests.js](https://github.com/johnwhitton/horizon/blob/main/scripts/newtest.js)


This seems to trigger an actual "bridging" but I am not sure if it is supposed to work. It covers some deployment and verification stuff, but doesn't seem to cover end-to-end

polymorpher · 2022-05-26T07:19:14Z

docs/README.md

+
+The assumption is that you need to just run the map, crossTo and crossBack functions.
+
+**Questions**


Move elsewhere? As to the questions, I suppose Bridge subcommands (the three you mentioned) can be used to do human-driven testing once deployment is complete. But they don't seem to be good for any automated testing. I don't think there is any end-to-end testing elsewhere

polymorpher · 2022-05-26T07:20:23Z

docs/README.md

+`yarn test` is set up as a script to run `npx hardhat test`
+
+**Questions**
+1. Is there any other branches where tests have been written?


Some PRs seem to be introducing useful tests, for example: https://github.com/harmony-one/horizon/pull/31/files

polymorpher · 2022-05-26T07:21:36Z

docs/README.md

+1. Is there any other branches where tests have been written?
+2. Are there any dependencies on tools or utils for these tests? 
+
+# Component Overview


This would be quite useful - let's make this a standalone doc

polymorpher · 2022-05-26T07:22:28Z

docs/README.md

+| 5.1     | bridge.hmy.js               |
+
+
+**Migration Strategy**


repeating some stuff above? see earlier "Migration Strategy"

polymorpher · 2022-05-26T07:23:12Z

Should we break this down to smaller pieces and target a non-main branch first?

…PR38 feedback and update docs/README.md

johnwhitton added 5 commits May 25, 2022 10:31

Update docs/README.md with status updates

3081dfc

update docs/README.md

fb40064

Update docs/README.md with additional deployment and testing notes an…

8f56192

…d questions

Update docs/README.md with Developer Setup and Testing guide

99e7707

Update docs/README.md with Developer Setup and Testing guide

1c923c1

polymorpher reviewed May 26, 2022

View reviewed changes

polymorpher mentioned this pull request May 26, 2022

Refactor #38

Merged

3 tasks

johnwhitton added 2 commits June 7, 2022 19:22

Merge upstream master

ff304dd

Pull latest main, remove hardhat.config.js, update DEVELOPER.md with …

1dc5a45

…PR38 feedback and update docs/README.md

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update Developer Guide #37

Update Developer Guide #37

johnwhitton commented May 25, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022 •

edited

Loading

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher May 26, 2022

polymorpher commented May 26, 2022


		## Creating the DAG Merkle Tree

		DAG genertion takes several hours to run Ganesha has a machine to do this and shares the latest DAG info from Ropsten using [google drive](https://drive.google.com/file/d/1FqLCO5oc1xDYNMuub7xAqnb6kfohdf-U/view?usp=sharing). The epoch logic is the block Number divided by 30,000 so current Ropsten EPOCH is block 12280236 / 30000 = 409 which is the DAG info shared above.


		There are also two scripts available [deploy_eth_side.js](https://github.com/johnwhitton/horizon/blob/main/scripts/deploy_eth_side.js) and [deploy_hmy_side.js](https://github.com/johnwhitton/horizon/blob/main/scripts/deploy_hmy_side.js)

		Questions


		The assumption is that you need to just run the map, crossTo and crossBack functions.

		Questions

Update Developer Guide #37

Are you sure you want to change the base?

Update Developer Guide #37

Conversation

johnwhitton commented May 25, 2022

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

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

polymorpher May 26, 2022 • edited Loading

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

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

polymorpher commented May 26, 2022

polymorpher May 26, 2022 •

edited

Loading