remove filecoin

lerna.json

@@ -1,5 +1,5 @@
 {
-  "packages": ["src/packages/*", "src/chains/*/*"],
+  "packages": ["src/*", "src/ethereum/*"],
   "version": "independent",
   "command": {
     "version": {

roadmap.md

@@ -0,0 +1,107 @@
+
+We need to create a roadmap document for a project called Transaction Simulation, it uses Ganache, the Ethereum simulator.
+
+
+
+What kind of people do we need and what areas of expertise?
+
+SysOps Engineer to handle architecture of production, dev systems, failover, automated deployment, monitoring, security, auth, etc.
+Ganache needs to be maintained full time (3 full time engineers) <- probably shouldn’t say this? 😅
+POC needs to be re-architected and engineered in a sane way, it’s currently a bit of a hack.
+We found a couple of bugs in ganache whilst working on this that we should go back and fix properly, as we just hacked in fixes without tests for the POC.
+Tests
+
+What needs to be done:
+
+Fully spec:
+
+`evm_simulateBatch` <- tenderly has this which allows simulating sets of transactions, each set being unrelated from the rest.
+`evm_simulateTransactions` <- the only thing we have now, but it’s a messy implementation.
+`evm_simulateTransaction` <- easy and nice to have
+`evm_simulate` -  simulate any RPC call and return an array of results. This seems useful? But no one has asked for it.
+
+A big question is: should we copy tenderly’s exactly? I don’t think so, because I think we can learn from what they built in build something more polished.
+
+In any case the simulate methods should accept `overrides` for each individual transaction, not a global `overrides` like we have implemented right now.
+
+Caching: we currently don’t attempt to sync our hot cache to “latest”, but doing this would improve performance of near-head simulations by about 50% (from ~70ms to 35ms, avg).
+
+We also don’t invalidate the cache in the cast of reorgs.
+
+As part of deployment, we need to figure out how to best serve and load balance instances of ganache, as well as manage the Erigon instance that acts as the data source. We need to determine hosting needs and a plan for rolling this out to end users.
+
+Perf: Gas tracer and stack tracer could be combined which could reduce complexity in some fragile areas.
+
+Security: we need to audit simulations to ensure that a contract can “figure out” it is in a simulation. For example: a malicious contract could check the gasLimit and determine that the gas limit is too high for mainnet, and then could return a false result because it is in a simulation environment. There are several vectors we’ll need to cover.
+
+Feature request from the POC feedback:
+
+Ethan on running multiple transactions where the first one fails:
+> yeah i’d prefer if it just stopped. It’s not like the second tx will provide much more info IMO than the one that initially reverted (edited)
+> it also makes it easier to check it something failed; length - 1, check if failed where the last item is always indicative of the most recent failure if it failed
+
+For this roadmap document, Ethan wants:
+
+> how many people, how long, what is going to be done
+> justification on why it needs to be done kind of thing
+
+
+– should we talk about Ganache maintenance in this document? Maybe this is a question for madeline
+
+Todos - we like this format
+Now
+Next
+Later
+
+Jeff Smale’s ramblings about milestones and order of implementation:
+The order of implementation should be such that we get the greatest value to our consumers the fastest. As such, "improvements" have been deferred in favour of more critical work in order to get a working solution into production.
+Core implementation
+Implement evm_simulateTranasctions RPC method including tracing, gas estimation, etc with the full functionality implemented in the PoC, but not necessarily with all of the optimisations required to achieve the performance.
+
+Head following mode, where the forked chain is followed locally, this is implemented in the PoC, but not necessarily in the same approach that we will want to take in the final product.
+Environmental build out
+Research and architect environmental architecture, including AWS frameworks, Erigon, Ganache instance(s), and potentially RPC Daemon instances, and deployment, monitoring, autoscaling etc.
+
+This will require research to ensure that we get the ideal balance of tradeoffs between performance, maintainability etc.
+Gas estimation improvements
+Improvements to the gas estimation approach to resolve issues where our current minimum gas estimation is incorrect. This could be an incremental approach where we identify the cases where we fail, falling back to a slow (binary search) implementation, and over time resolve some of those issues in order to improve gas estimation performance
+Performance and scalability
+Incrementally implement performance and scalability improvements, such as high-performance in-memory database, high performance step interception, and other "non-critical"
+changes.
+
+ ---
+
+# Roadmap:
+
+1. Introduction
+2. Project Goals
+3. Required Expertise and Team Composition
+4. Required Specifications
+5. Project Timeline and Milestones
+6. Justification
+
+
+## Introduction
+
+Ganache is an Ethereum simulator that makes developing Ethereum applications faster, easier, and safer. It includes all popular RPC functions and features of an Ethereum RPC client, plus the ability to manipulate the chain in ways a testnet/mainnet client would not. This ability to manipulate the chain is immensely helpful for users that want to simulate an Ethereum state that does not currently exist.
+
+We have developed a Proof of Concept of a new RPC endpoint, evm_simulateTransactions, that allows for users, like MetaMask, to send transactions for Ganache to simulate, in order, complete with state overrides, call tracing, and gas estimation. We’re hosting this endpoint via AWS to make it available for testing.
+
+This roadmap document outlines what it will take to graduate this PoC into a stable production-ready service with the uptime-reliability and scalability MetaMask requires.
+
+
+## Project Goals
+
+The goal of this project is to graduate the PoC into a stable production-ready service with the uptime-reliability and scalability MetaMask requires.
+
+This project will be considered complete when the following criteria are met:
+
+- The evm_simulateTransactions endpoint is available for use by MetaMask and other users.
+- The endpoint is hosted in a production-ready environment with the uptime-reliability and scalability MetaMask requires.
+- The endpoint is well-documented and easy to use.
+- The endpoint is well-tested and has a test suite that is easy to run.
+- The endpoint is well-monitored and has alerting in place for critical issues.
+- The endpoint is well-maintained and has a plan for future maintenance and improvements.
+- The endpoint is well-secured and has a plan for future security improvements.
+- The endpoint is well-supported and has a plan for future support.
+- The endpoint is well-architected and has a plan for future architectural improvements.