diff --git a/LICENSE b/LICENSE
new file mode 100644
index 000000000..5c2b52849
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2021 Covalent
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/README.md b/README.md
index 9b384b6b5..39b3f56e6 100644
--- a/README.md
+++ b/README.md
@@ -1,11 +1,44 @@
-# Block Specimen Producer (Go Ethereum)
+
+
+
+
+
+# Block Specimen Producer (BSP Geth)
* [Introduction](#bsp_intro)
* [Resources](#bsp_resources)
+* [Raison d'être](#bsp_why)
* [Architecture](#bsp_arch)
* [Build & Run](#build_run)
* [Flag Definitions](#flag_definitions)
-* [Contributing](CONTRIBUTING.md)
+* [Contributing](./docs/CONTRIBUTING.md)
+* [Go Ethereum](#geth)
## Introduction
@@ -27,11 +60,11 @@ As a result, anyone can run full tracing on the block specimen and accurately re
Production of Block Specimen Objects (BSOs) forms the core of the network’s data objects specification. These objects are created with the aid of three main pieces of open-source software provided by Covalent for the network’s decentralized stack.
-1. [Block Specimen Producer (BSP) - Operator run & deployed](https://github.com/covalenthq/go-ethereum)
+1. [Block Specimen Producer (BSP Geth)](https://github.com/covalenthq/go-ethereum) - Operator run & deployed
-1. [BSP Agent - Operator run & deployed](https://github.com/covalenthq/mq-store-agent)
+1. [BSP Agent](https://github.com/covalenthq/mq-store-agent) - Operator run & deployed
-1. [BSP Proof-chain - Covalent operated & pre-deployed](https://github.com/covalenthq/cqt-virtnet)
+1. [BSP Proof-chain](https://github.com/covalenthq/cqt-virtnet) - Covalent operated & pre-deployed
Please refer to these [instructions](https://docs.google.com/document/d/1BMC9-VXZfpB6mGczSu8ylUXJZ_CIx4ephepDtlruv_Q/edit?usp=sharing) for running the BSP with the mq-store-agent (BSP Agent).
@@ -49,8 +82,11 @@ However, this is only one side of the scalability issue that troubles the space.
One common method of reading data from Ethereum for example is the JSON RPC Layer. A number of issues present themselves however when doing so.
- **Slow**: One needs to make a series of individual data queries to extract the block and its constituent elements like transactions and receipts.
+
- **Not Multiversion**: Multiversion concurrency control methods are traditionally employed in databases to ensure point-in-time consistent views if multiple parties are viewing or querying the database. Such methods do not exist in web3.
+
- **Expensive**: To access historical data at any point in time, you need to run your blockchain clients in a mode known as “full archive nodes” - which requires specialized and expensive hardware to scale.
+
- **The Purge:** For Ethereum specifically, Vitalik recently outlined an updated roadmap for its development which included a phase titled ‘The Purge’. Once this phase is implemented, clients will no longer store historical data older than a year. Hence, alternatives will be needed to access Ethereums full historical state.
Meanwhile, data mappers and static dashboards are great for examining specific metrics and small tables (so long as the smart contract is decoded) but lack flexibility and scalability. Our belief is that -
@@ -63,13 +99,20 @@ The Block Specimen is **the solution** to tackle the read scalability issues tha
## Architecture
-
+
While BSOs are currently being created internally at Covalent for each respective blockchain indexed, the Covalent Network shifts this responsibility to operators (anyone performing a role on the Covalent Network). Any operator on the network will be able to opt in to act as a Block Specimen Producer (BSP).
To ensure that the data within the block-specimens that operators create is reliable and honest, a production proof is created for every BSO produced. These will be published to proofing contract deployed by Covalent. Therefore, BSO proofs can be compared and any deviations in the data either accidentally or malicious will have mismatching proofs.
-In sum, it is the responsibility of the BSPs to consume blocks from external blockchains and publish both the BSP along with a production proof to the Covalent virtual chain. BSPs play a pivotal role in the network given that the data in the BSO will feed the entire network with the data needed to answer user queries.Of course, operators who successfully perform this role will be compensated in CQT.
+
+
+
+In sum, it is the responsibility of the BSPs to consume blocks from external blockchains and publish both the BSP along with a production proof to the Covalent virtual chain. As the network is developed, Covalent will be shifting the responsibility of running the Block Specimen software to operators (anyone performing a role on the Covalent Network). These Block Specimens will consume blocks from external blockchains and feed the entire network with the data needed to answer user queries.
+
+How does this create and accrue value for the Covalent Network? As Block Specimens publish more data to Covalent Network, developers will be attracted. With a growing developer base on the Covalent Network, there will be a greater appetite for blockchain data. And hence, the cycle begins again, with Block Specimens expected to meet this demand for data.
+Of course, operators who successfully perform this role will be compensated in CQT.
+
## Build & Run
@@ -161,7 +204,7 @@ If it doesn’t - the BSP - producer isn't producing messages! In this case plea
If both `--replica-result` & `--replica-specimen` are selected then a `block-replica` is exported containing all the fields for exporting any block fully alongwith its stored state.
-## Go Ethereum
+## Go Ethereum
Official Golang implementation of the Ethereum protocol.
diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md
new file mode 100644
index 000000000..ae5b7bf2b
--- /dev/null
+++ b/docs/CONTRIBUTING.md
@@ -0,0 +1,132 @@
+# Contributing
+
+* [Reporting Bugs](#bugs)
+* [General Procedure](#general_procedure)
+ * [Development Procedure](#dev_procedure)
+ * [Dependencies](#dependencies)
+ * [Testing](#testing)
+ * [Branching Model and Release](#braching_model_and_release)
+ * [PR Targeting](#pr_targeting)
+ * [Pull Requests](#pull_requests)
+ * [Process for reviewing PRs](#reviewing_prs)
+ * [Pull Merge Procedure](#pull_merge_procedure)
+
+
+## Reporting Bugs
+
+Please file bugs in the [GitHub Issue
+Tracker](https://github.com/covalenthq/go-ethereum). Include at
+least the following:
+
+ - What happened
+ - What did you expect to happen instead of what *did* happen, if it's
+ not crazy obvious
+ - What operating system, operating system version and version of
+ go-ethereum you are running
+ - Console log entries, where possible and relevant
+
+If you're not sure whether something is relevant, erring on the side of
+too much information will never be a cause for concern.
+
+
+## General Procedure
+
+Contributing to this repo can mean many things such as participating in discussion or proposing code changes. To ensure a smooth workflow for all contributors, the following general procedure for contributing has been established:
+
+1. Either [open](https://github.com/covalenthq/go-ethereum/issues/new/choose)
+ or [find](https://github.com/covalenthq/go-ethereum/issues) an issue you have identified and would like to contribute to
+ resolving.
+
+2. Participate in thoughtful discussion on that issue.
+
+3. If you would like to contribute:
+ 1. If the issue is a proposal, ensure that the proposal has been accepted by the Covalent team.
+ 2. Ensure that nobody else has already begun working on the same issue. If someone already has, please make sure to contact the individual to collaborate.
+ 3. If nobody has been assigned the issue and you would like to work on it, make a comment on the issue to inform the
+ community of your intentions to begin work. Ideally, wait for confirmation that no one has started it. However,
+ if you are eager and do not get a prompt response, feel free to dive on in!
+ 4. Follow standard Github best practices:
+ 1. Fork the repo
+ 2. Branch from the HEAD of `main`(For core developers working within the go-ethereum repo, to ensure a clear ownership of branches, branches must be named with the convention `{moniker}/{issue#}-branch-name`).
+ 3. Make commits
+ 4. Submit a PR to `main`
+ 5. Be sure to submit the PR in `Draft` mode. Submit your PR early, even if it's incomplete as this indicates to the community you're working on something and allows them to provide comments early in the development process.
+ 6. When the code is complete it can be marked `Ready for Review`.
+ 7. Be sure to include a relevant change log entry in the `Unreleased` section of `CHANGELOG.md` (see file for log
+ format).
+ 8. Please make sure to run `gofmt` before every commit - the easiest way to do this is having your editor run it for you upon saving a file. Additionally, please ensure that your code is lint compliant by running `make lint` . There are CI tests built into the Evmos repository and all PR’s will require that these tests pass before they are able to be merged.
+
+**Note**: for very small or blatantly obvious problems (such as typos), it is not required to open an issue to submit a
+PR, but be aware that for more complex problems/features, if a PR is opened before an adequate design discussion has
+taken place in a github issue, that PR runs a high likelihood of being rejected.
+
+Looking for a good place to start contributing? How about checking out
+some [good first issues](https://github.com/covalenthq/go-ethereum/issues).
+
+### Development Procedure
+
+1. The latest state of development is on `main`.
+2. `main` must never
+ fail `make lint, make geth, make all `
+3. No `--force` onto `main` (except when reverting a broken commit, which should seldom happen).
+4. Create your feature branch from `main` either on `github.com/covalenthq/go-ethereum`, or your fork (
+ using `git remote add origin`).
+5. Before submitting a pull request, begin `git rebase` on top of `main`.
+
+
+### Dependencies
+
+We use [Go Modules](https://github.com/golang/go/wiki/Modules) to manage dependency versions.
+
+The master branch of every Cosmos repository should just build with `go get`, which means they should be kept up-to-date
+with their dependencies, so we can get away with telling people they can just `go get` our software.
+
+Since some dependencies are not under our control, a third party may break our build, in which case we can fall back
+on `go mod tidy -v`.
+
+### Testing
+
+Covalent uses [GitHub Actions](https://github.com/features/actions) for automated [integration testing](https://github.com/covalenthq/go-ethereum/actions).
+
+### Branching Model and Release
+
+User-facing repos should adhere to the [trunk based development branching model](https://trunkbaseddevelopment.com/).
+
+Libraries need not follow the model strictly, but would be wise to.
+
+Evmos utilizes [semantic versioning](https://semver.org/).
+
+### PR Targeting
+
+Ensure that you base and target your PR on the `main` branch.
+
+All feature additions should be targeted against `main`. Bug fixes for an outstanding release candidate should be
+targeted against the release candidate branch.
+
+### Pull Requests
+
+To accommodate the review process, we suggest that PRs are categorically broken up. Ideally each PR addresses only a
+single issue. Additionally, as much as possible code refactoring and cleanup should be submitted as separate PRs from
+bug fixes/feature-additions.
+
+### Process for reviewing PRs
+
+All PRs require two Reviews before merge. When reviewing PRs, please use the following review explanations:
+
+1. `LGTM` without an explicit approval means that the changes look good, but you haven't pulled down the code, run tests
+ locally and thoroughly reviewed it.
+2. `Approval` through the GH UI means that you understand the code, documentation/spec is updated in the right places,
+ you have pulled down and tested the code locally. In addition:
+ * You must think through whether any added code could be partially combined (DRYed) with existing code.
+ * You must think through any potential security issues or incentive-compatibility flaws introduced by the changes.
+ * Naming convention must be consistent with the rest of the codebase.
+ * Code must live in a reasonable location, considering dependency structures (e.g. not importing testing modules in
+ production code, or including example code modules in production code).
+ * If you approve of the PR, you are responsible for fixing any of the issues mentioned here.
+3. If you are only making "surface level" reviews, submit any notes as `Comments` without adding a review.
+
+### Pull Merge Procedure
+
+1. Ensure pull branch is rebased on `main`.
+2. Ensure that all CI tests pass.
+3. Squash merge pull request.
\ No newline at end of file
diff --git a/arch.jpg b/docs/arch.jpg
similarity index 100%
rename from arch.jpg
rename to docs/arch.jpg
diff --git a/docs/covalent.jpg b/docs/covalent.jpg
new file mode 100644
index 000000000..54f33bdc7
Binary files /dev/null and b/docs/covalent.jpg differ
diff --git a/docs/value.png b/docs/value.png
new file mode 100644
index 000000000..680d0b162
Binary files /dev/null and b/docs/value.png differ
+
+
+ 
+
+
+ 
+
+
+ 
+