Update README.md

Author: ethernomad

README.md

@@ -30,25 +30,19 @@ The Hybrid indexer is written in Rust. It can be configured to connect to any Su
 
 It reads events in all blocks using [subxt](https://github.com/paritytech/subxt) and index these events in a Key-value database using the [sled](http://sled.rs/) library. This is considerably more efficient than storing the index in an SQL database.
 
-subxt currently has an [issue](https://github.com/paritytech/subxt/issues/793#issuecomment-1386902010) where it is not possible to query blocks prior to V14 metadata (block #7,229,126 on Polkadot). Resolving this issue is not within the scope of the grant. Once this grant is completed a further grant application will be made that includes resolving this issue.
-
-When decoding events, subxt needs to have the correct metadata. The metadata changes whenever a chain performs a runtime upgrade. Hybrid Indexer handles this in a very elegant way. When indexing begins it downloads the metadata for the starting block. When it encounters a decoding error it downloads the metadata for the current block and retries decoding. This means that the indexer does not have to be built with the metadata and block number of every runtime upgrade.
-
-To index an event, it needs to be converted into a Rust type that matches the metadata. Sometimes the metadata for an event will change during a runtime upgrade. To handle this the indexer will have Rust types for current and historic versions of all events. When an event fails to be converted into a Rust type the previous type will be tried.
-
 All events in all pallets that have identifying parameters will be indexed. For example the Transfer event in the Balances pallet is identifiable by the `AccountId` of both `from` and `to`.
 
 Other examples of identifying event parameters are `assetId` in the Assets pallet, `code_hash` in the contracts pallet, `CollectionId` and `ItemId` in the NFTs pallet, and `MultiLocation` in the XCM pallet.
 
 Additionally, all events are indexed by event variant.
 
-To download a block, a query first has to be made to determine the hash for a given block number. In order to ensure throughput is as high as possible, multiple queries to the full node will be active at the same time to avoid round-trip delay. Block processing will be in a separate thread. 
+To download a block, a query first has to be made to determine the hash for a given block number. In order to ensure throughput is as high as possible, multiple queries to the full node will be active at the same time to avoid round-trip delay.
 
 In the same manner that each Substrate chain is a separate Rust build that uses Substrate crates, each chain will need a separate Hybrid Indexer build that is configured to index the correct pallets.
 
 When a chain is going to potentially perform a runtime upgrade, the Hybrid Indexer for the chain will need a new release with any updated events. If an instance of the indexer is not updated before the runtime upgrade occurs, it can be restarted with the new version at the correct block number.
 
-WSS queries will be handled via the highly scalable [tokio_tungstenite](https://github.com/snapview/tokio-tungstenite) Rust library.
+WSS queries are handled via the highly scalable [tokio_tungstenite](https://github.com/snapview/tokio-tungstenite) Rust library.
 
 In addition to the identifier being searched for, queries will be able to include start block, offset, and limit to control which events are returned.
 
@@ -59,126 +53,3 @@ The database keys will be constructed in such a way so that events can be found
 `AccountId/BlockNumber/EventIndex`
 
 Database entries will be key-only. No value will be stored. The blocknumber and event index are all that need to be returned for each event found. This reduces the size of the index database and increases decentralization. The frontend can query the chain in a decentralized manner to retrieve the event.
-
-### Tutorial
-
-Hybrid is still early in the development process. Currently it can index event parameters from many events in Polkadot: AccountId, AccountIndex, AuctionIndex, BountyIndex, CandidateHash, EraIndex, MessageId, ParaId, PoolId, PreimageHash, ProposalHash, ProposalIndex, RefIndex, RegistrarIndex, SessionIndex, TipHash. Additionally, all events are indexed by event variant.
-
-#### Run tests
-
-```
-cargo test
-```
-
-#### Build
-
-```
-cargo build --release
-```
-
-#### Run indexer
-
-```
-./target/release/hybrid-indexer --block-height 15870000 
-```
-
-The earlist block that can be indexed on Polkadot is 7,229,126.
-
-The indexer simultaneously indexes historical blocks (batch) and finalized blocks (head).
-
-When the indexer starts it will start batch indexing from where indexing finished last time it was run. This can be overidden with the --block-height parameter.
-
-Head blocks are always indexed as they are finalized. Once batch indexing has caught up with head it will stop and only blocks being finalized will be indexed.
-
-#### Run the dapp
-
-Go to [hybrid-dapp](https://github.com/hybrid-explorer/hybrid-dapp/tree/milestone-2) and follow the tutorial to run the frontend to query the indexer.
-
-### Docker
-
-After setting up Docker, run the following command to build the image:
-
-```
-docker build .
-```
-
-Then run the image with the correct port mapping:
-
-```
-docker run --rm -p 8172:8172 [image_hash]
-```
-
-Now run the dockerfile for [hybrid-dapp](https://github.com/hybrid-explorer/hybrid-dapp/tree/milestone-2#docker).
-
-### Testing Guide
-
-Ensure that you have both the the indexer and dapp running, either by following the above tutorial, or by following the Docker instructions.
-
-#### Deliverable 2.1 & 2.2
-
-Event subscription API / Live dapp
-
-1. Select Pallet / Variant search key.
-2. Select Balances pallet.
-3. Select Transfer variant.
-4. Click Search.
-5. Observe that as new balance transfers occur on Polkadot, they automatically appear in the results.
-
-#### Deliverable 2.3
-
-preimage_hash, era_index and session_index are now indexed in addition to the keys in milestone 1.
-
-Using the dapp, test the following search queries and verify the results:
-
-```
-PreimageHash: 0xdb2b6cb38c2f6704ed067da2e9001bc57314be4f0117f664a93c0d18610110c5
-15764612	preimage	Noted	A preimage has been noted.
-hash_: 0xdb2b6cb38c2f6704ed067da2e9001bc57314be4f0117f664a93c0d18610110c5
-```
-
-```
-EraIndex: 1076
-15825858	fastUnstake	BatchChecked	A batch was partially checked for the given eras, but the process did not finish.
-eras: [ "1,076" ]
-```
-
-```
-SessionIndex: 6552
-15649648	session	NewSession	New session has happened. Note that the argument is the session index, not the block number as the type might suggest.
-sessionIndex: 6,552
-```
-
-#### Deliverable 2.4
-
-All events are now indexed by their variant.
-
-1. Select Pallet / Variant search key.
-2. Select System pallet.
-3. Select NewAccount variant.
-4. Click Search.
-5. Observe that events with the selected variant are found.
-
-#### Deliverable 2.5
-
-Event contents are now loaded directly from the chain, rather than from the indexer.
-
-Observe that when searching for events, the details column is populated with information about the event.
-
-#### Deliverable 2.6
-
-Asynchrous block downloading - blocks will be downloaded as fast as possible for improved indexing speed.
-
-In the previous milestone the indexer downloaded blocks one at a time. Blocks indexed per second was in the single digits.
-
-Now the indexer maintains up to 128 current requests. This results in approx 100x increase in block indexing rate.
-
-Observe that when batch indexing, the indexer reports blocks per second in the triple digits.
-```
- 📚 #15870600, 155 blocks/sec
- 📚 #15870700, 179 blocks/sec
- 📚 #15870800, 136 blocks/sec
- 📚 #15870900, 158 blocks/sec
- 📚 #15871000, 284 blocks/sec
- 📚 #15871100, 161 blocks/sec
- 📚 #15871200, 168 blocks/sec
-```