Data ring --------- Adrian recording action items. **Jay intro.** Concerns: | | On Chain | Off Chain | | -------- | -------- | -------- | | **Consented to** | Hash | | | **Not consented to** | | Blockchain explorers (we accept their data without question) | Problem with unbounded growth of data. Pawns of a larger Google Let's make a list of the things we're concerned about Growth of data, delivery of data. Other intros: - **Vlad**: wants standardization. Abstraction layer over standards -- let's understand data over different apps and different standards. - **Wei**: Wants to merge on-chain with real time data - **Peter** - **Afri** - Problem with blockchain requests getting served by Infura. - **Jakub** - offchain data - block explorers - **Mutab (sp)** (Polymath) - Time to sync the node is a problem. - **Kenovides (sp)** () - **Matt** - IPFS - make user experience better for data type things. Never gonna see adoption - **Ben** - built a block explorer. Can try to represent vulcanizedb's viewpoint with IPFS. - **Thomas?** - **Ronan** - very fast access to chain - **Jamie** - operates tracing node. accounting: reliance on etherscan. Wants to know that balance is verifiably at this block, accessible to accountants that have Excel. - **Juus** - data & economy. - **philipp** - economics for onchain data that's more sustainable. Wants to reduce trust. - **Adrian** - wants multiple representation of block data. By account, etc. Doesn't want to download terabytes. - **Michael Cena** - associate offchain data to ethereum address (object to profile). - **EG** - runs nodes for the public. wants to set criteria for full node. Syncing problems. - **Josh** - dapp says "start syncing from block 2000" if the dapp only needs from there. - **Luke** - concerned about 1 time payment for storage model and implication for application. - **Alex** - graph based data, adding metadata. - **Philippe** - Less storage, more logs(events) - **Matt** - block explorers. - Others as well. Hard to get all the names. Jay's concern: future promise of "release of position of centrality" feels dangerous. Becomes increasingly difficult. Jamie: Understand why this situation exists and how can we liberate the situation? How can the person that wants to start an acceptable service generate the idea and bring it to market? UX guy - a service that can prove that the data is valid. Jay: Deny access to the data. Charge increasingly higher prices. Distinguish between data derived from chain, and meta data (price data). Mixing of meta data and block data. Adrian: every block has a hash. how can we verify block 6000000? Afri: Need the state. Difference between state root and state. Adrian: Do we have the "every 1000 blocks finalish hash" Ben/Afri: Warp sync. If you want a certain block, you have a hash, and you download the state from other nodes, then you can verify and check if the state makes sense. State is several gigs. How big is full state of Ethereum network? Ben: Current proof of work, don't ask for finality. Phillipp: Discussing what happens to data once we're in ethereum 2.0. Will we have finality then? Jay: Can we agree that community would benefit from getting as close as possible to provable data? 1 way: through the node. another way: api providing provable extraction. Jamie: Oracle service. What's the attack? Afri: You cannot verify the data because we are using metamask and infura. Jamie: big jump between full node and infura. Let's talk about verifiability at each tier. Targeted attacks at well. Target around the node. Ben: data availability attack. Different discussion. How do we manage this discussion? How do we know we're not being spoofed? Adrian: As we get to thousands of transactions per second (sharding, etc) then what happens? Jay: call to actions? Josh: let's create categories around what we talked about. **Categories:** - growth of data - node compensation - optimizing data structure - making it better to run a node. incentivization is data they get. Adrian: Can we put something into the block to help us with this problem? e.g. putting a hash of the state in ipfs and in every 10,000 block headers? Put stuff on IPFS independently of the node client. E.g. : People are doing this, putting it into google bigquery, etc. It's really difficult to extract the data. Looking at historical account balances shouldn't be that difficult. Jamie: More education. Jay: ETHPrize offering to pay bounties. Could be a bounty for article. Afri wrote a great article already, we should have more. Keeping the node in sync. Jay never wanted to scale for the whole world; just wanted to extract the data from the node for himself. Mom & Pop users can't run a node. Let's help them. Not enough nodes in network. solvable by incentivizing. Adrian: The way the data is currently structured doesn't allow you to get your data. Wants new structure for data: e.g. If we partitioned it into 40,000 partitions, if I have 10 accounts, I'd only have to get 10 of those partitions. Some more discussion about how to make it easier for the user to get their data. Jay: last 5 minutes, let's get people to write articles. EG: Syncing Vlad: sharing data EG: Create tooling to monitor the state size. just does df. Community needs tool to get the size and place to store the metrics. Topic a guy wishes was covered: How can we have l2 services to prove that certain data was on the blockchain. staking, snarks? Wants economical guarantees that the data was served is valid. Session was way too short. We're all joining magicians forum, data category.