Add initial draft of Flow EVM Gateway FLIP

application/20240103-evm-gateway.md

@@ -0,0 +1,123 @@
+---
+status: draft 
+flip: [234](https://github.com/onflow/flips/pull/234)
+authors: Ardit Marku ([email protected]) 
+sponsor: Jerome Pimmel ([email protected]) 
+updated: 2024-01-03 
+---
+
+# FLIP 234: Flow EVM Gateway. An implementation of the Ethereum JSON-RPC API specification
+
+## Objective
+
+What are we doing and why? What problem will this solve? What are the goals and
+non-goals? This is your executive summary; keep it short, elaborate below.
+
+## Motivation
+
+Why is this a valuable problem to solve? What background information is needed
+to show how this design addresses the problem?
+
+Which users are affected by the problem? Why is it a problem? What data supports
+this? What related work exists?
+
+## User Benefit
+
+How will users (or other contributors) benefit from this work? What would be the
+headline in the release notes or blog post?
+
+## Design Proposal
+
+This is the meat of the document where you explain your proposal. If you have
+multiple alternatives, be sure to use sub-sections for better separation of the
+idea, and list pros/cons to each approach. If there are alternatives that you
+have eliminated, you should also list those here, and explain why you believe
+your chosen approach is superior.
+
+Make sure you’ve thought through and addressed the following sections. If a 
+section is not relevant to your specific proposal, please explain why, e.g. 
+your FLIP addresses a convention or process, not an API.
+
+### Drawbacks
+
+Why should this *not* be done? What negative impact does it have? 
+
+### Alternatives Considered
+
+* Make sure to discuss the relative merits of alternatives to your proposal.
+
+### Performance Implications
+
+* Do you expect any (speed / memory)? How will you confirm?
+* There should be microbenchmarks. Are there?
+* There should be end-to-end tests and benchmarks. If there are not 
+(since this is still a design), how will you track that these will be created?
+
+### Dependencies
+
+* Dependencies: does this proposal add any new dependencies to Flow?
+* Dependent projects: are there other areas of Flow or things that use Flow 
+(Access API, Wallets, SDKs, etc.) that this affects? 
+How have you identified these dependencies and are you sure they are complete? 
+If there are dependencies, how are you managing those changes?
+
+### Engineering Impact
+
+* Do you expect changes to binary size / build time / test times?
+* Who will maintain this code? Is this code in its own buildable unit? 
+Can this code be tested in its own? 
+Is visibility suitably restricted to only a small API surface for others to use?
+
+### Best Practices
+
+* Does this proposal change best practices for some aspect of using/developing Flow? 
+How will these changes be communicated/enforced?
+
+### Tutorials and Examples
+
+* If design changes existing API or creates new ones, the design owner should create 
+end-to-end examples (ideally, a tutorial) which reflects how new feature will be used. 
+Some things to consider related to the tutorial:
+    - It should show the usage of the new feature in an end to end example 
+    (i.e. from the browser to the execution node). 
+    Many new features have unexpected effects in parts far away from the place of 
+    change that can be found by running through an end-to-end example.
+    - This should be written as if it is documentation of the new feature, 
+    i.e., consumable by a user, not a Flow contributor. 
+    - The code does not need to work (since the feature is not implemented yet) 
+    but the expectation is that the code does work before the feature can be merged. 
+
+### Compatibility
+
+* Does the design conform to the backwards & forwards compatibility [requirements](../docs/compatibility.md)?
+* How will this proposal interact with other parts of the Flow Ecosystem?
+    - How will it work with FCL?
+    - How will it work with the Emulator?
+    - How will it work with existing Flow SDKs?
+
+### User Impact
+
+* What are the user-facing changes? How will this feature be rolled out?
+
+## Related Issues
+
+What related issues do you consider out of scope for this proposal, 
+but could be addressed independently in the future?
+
+## Prior Art
+
+Does the proposed idea/feature exist in other systems and 
+what experience has their community had?
+
+This section is intended to encourage you as an author to think about the 
+lessons learned from other projects and provide readers of the proposal 
+with a fuller picture.
+
+It's fine if there is no prior art; your ideas are interesting regardless of 
+whether or not they are based on existing work.
+
+## Questions and Discussion
+
+State where you would want the community discussion to take place (choosing between the PR itself, or forum post)
+Seed with open questions you require feedback on from the FLIP process. 
+What parts of the design still need to be defined?