-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
polygon integration #2319
Comments
Wanted to try out v0.3.9-beta with the harness, but something is missing with keystore:
Before that with the nodes root:
That's with |
Actually, I've been wondering about eth too, why do we have a toml/conf file if everything seems to be given as cli args (or can be)? |
Right!?. |
I was able to start the server but got this error:
|
I'd like to try but it keeps saying keystore files are missing when I
To test your branch @buck54321 is the create-harness.sh the same as with eth? Or did you forget to add/commit the file? |
@chappjc, try with these changes here 65ac0bc |
Nice @ukane-philemon , thanks! |
Running Also, we can't specify the
Logs
</details? |
I've sketched out the client bits and have started looking into a harness.
buck54321/dcrdex@8d990a1...buck54321:dcrdex:polygon
The harness is proving to be difficult. Typically, with Polygon, you'd run the POS component called Heimdall. I don't know if that's an option for us. but I'm trying to avoid it. Then you run the geth-like part, called
bor
. To runbor
without Heimdall, they've provided some development flags. @chappjc found maticnetwork/bor#697. I've built the development branch and supplied a genesis file (which is just a copy of their testnet file with the network ID changed), and supplied the development flags, but the node is still looking for Heimdall, it appears.IMPORTANT: 1) The requisite CLI flags are only found on their
development
branch. 2) Thebor
executable that needs to be inPATH
is actuallybor/cmd/cli
, which compiles to an executable namedcli
. I just copied it to one of myPATH
directories renamed tobor
.⭐ Anyway. If we can't figure it out, I propose that we just run another Ethereum simnet for the Polygon harness. We're really only interested in the RPC API, and Polygon should be compatible with Ethereum. On top of that, this would facilitate the development of an ethereum "base harness", which other EVM-compatible assets can leverage in their asset-integration process.
To Do
We can potentially split this work into 3 parts.
It'd be best to get the 1 done before 2 or 3. So I'd like to figure it out ASAP. Anyone object to using an Ethereum simnet?
The text was updated successfully, but these errors were encountered: