Integrate Foundry Into the go-ethereum Repository #206

New Issue

2022-03-10T21:58:06Z

abdulrabbani00 commented

2022-03-10 21:58:06 +00:00

(Migrated from github.com)

Rationale

Why should this feature exist?

Currently, to build geth locally and test it we rely on our implementation of the dapptools repository. While the dapptools repository starts a docker container with a running instance of Geth there are a few inefficiencies:
- We have to use a separate GitHub repository to simply build the code in this repository.
- dapptools can take a long time to download all of its dependencies.
- There seems to be a lot of "fluff" in dapptools that is not useful.
- Our version of dapptools is far behind the upstream repository. We are currently burdened with having to maintain it.
Utilizing foundry in vulcanize-geth can have the following benefits:
We can easily start a docker container with a local version of geth from the vulcanize-geth repository.
We can have faster build times.
Foundry seems to be a more robust testing framework for smart contracts. We can test smart contract logic in solidity (This can be a double-edged sword).
What are the use-cases?
We can create a CI/CD pipeline that builds the local version of geth, runs it, and tests any smart contract against it, all from one repository.
It can make local and integration testing more feasible.

Implementation

Do you have ideas regarding the implementation of this feature?

I think integration would be as follows:

Take apart our current implementation of dapptools. From what I gather, all dapptools is doing for us is:
a. Downloads a remote version of geth
b. Spins up a docker image with all the necessary dependencies (this takes forever).
c. Runs Geth with special configurations.
d. Sends transactions to geth.
The implementation for Foundry would be as follows:
a. Compile geth based on the current Dockerfile.
b. Spin up a docker container with Foundry.
c. Runs Geth with special configurations (the same way we are doing with dapptools).
d. Sends transactions to geth. Instead of using seth we would use Foundry's cast implementation.

Are you willing to implement this feature?
I am willing to implement this along with the following PR.

# Rationale Why should this feature exist? * Currently, to build geth locally and test it we rely on our implementation of the [dapptools](https://github.com/vulcanize/dapptools) repository. While the dapptools repository starts a docker container with a running instance of Geth there are a few inefficiencies: * We have to use a separate GitHub repository to simply build the code in this repository. * dapptools can take a long time to download all of its dependencies. * There seems to be a lot of "fluff" in dapptools that is not useful. * Our version of dapptools is __far__ behind the upstream repository. We are currently burdened with having to maintain it. * Utilizing foundry in [vulcanize-geth](https://github.com/vulcanize/go-ethereum) can have the following benefits: * We can easily start a docker container with a local version of geth from the vulcanize-geth repository. * We can have faster build times. * Foundry seems to be a more robust testing framework for smart contracts. We can test smart contract logic in solidity (This can be a double-edged sword). What are the use-cases? * We can create a CI/CD pipeline that builds the local version of geth, runs it, and tests any smart contract against it, all from one repository. * It can make local and integration testing more feasible. # Implementation Do you have ideas regarding the implementation of this feature? I think integration would be as follows: 1. Take apart our current implementation of dapptools. From what I gather, all dapptools is doing for us is: a. Downloads a remote version of geth b. Spins up a docker image with all the necessary dependencies (this takes forever). c. Runs Geth with special configurations. d. Sends transactions to geth. 2. The implementation for Foundry would be as follows: a. Compile geth based on the current Dockerfile. b. Spin up a docker container with Foundry. c. Runs Geth with special configurations (the same way we are doing with dapptools). d. Sends transactions to geth. Instead of using `seth` we would use Foundry's `cast` implementation. Are you willing to implement this feature? I am willing to implement this along with the following [PR](https://github.com/vulcanize/go-ethereum/issues/181).

abdulrabbani00 commented

2022-03-11 16:33:21 +00:00

(Migrated from github.com)

https://github.com/vulcanize/go-ethereum/issues/207

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/go-ethereum#206

Integrate Foundry Into the go-ethereum Repository #206

Rationale

Implementation

Integrate Foundry Into the `go-ethereum` Repository #206