---- https://twitter.com/liamzebedee/status/1688728259402588160 https://liamz.co/tech-blog/2023/07/10/on-cryptonetworks-vs-federated-hubs-and-p2p.html **gigapass** summon bittorrent swarms to host datasets, on-chain buy capture-resistant hosting from a protocol, not a company problem: - you want to buy a .eth domain and host data on it, all inside a dapp solution: - buy the .eth, upload your data to Gigaupload, and pay for X months of hosting. let the AMM do the rest. how it works: - Gigaupload is a protocol that operates a data hosting market - nodes onboard and provide bandwidth and storage - the AMM prices bandwidth and latency automatically - users spend $GGA to buy p2p hosting services why? - blockchains cannot host files - arweave/filecoin's networks sell data storage, not distribution. - arweave/filecoin's networks are inflexible to download demand. fixed capacity of nodes, constrained by stake requirements. - bittorrent's network **is** flexible to demand - see [149,000 users downloading one file](https://torrentfreak.com/5-torrent-files-that-broke-mind-boggling-records-101107/) - we don't have to run our own blockchain to deploy protocols. so why do we have to run an IPFS node to deploy hosting? - we need a market for hosting. that prices transactions according to supply and demand of bandwidth. cryptographically. - we need surge pricing for download, to incentivise bittorrent nodes to come online. why bittorrent? - it's legitimately decentralized. unlike most cryptonetworks, bittorrent does not run predominantly on AWS. anyone can run a bittorrent client on consumer-grade hardware. - existing decentralized market. those who run bittorrent nodes profesionally, are already running it outside of the centralized cloud - many seedbox businesses already exist, connected in their own data centres. what can you use it for? - e.g. dapps, ML models, big media (movies, images) - removing the "human in the loop" for DAO's. now your DAO can buy hosting services for dapps completely **on-chain**, using smart contracts. how does the tech work? - gigapass operates like a blockchain - bandwidth/storage are calculated like gas on ethereum, and priced automatically - nodes run a probabilistic proof-of-transfer protocol improvement delta: - ipfs. 2x. too hard to host a torrent using bittorrent software. - filecoin. 10x. can't buy storage easily. - arweave. 3x-10x. can't host big files, no guarantees on speed, doesn't scale download demand. - bittorrent node. 3x. can buy hosting (whatbox etc.). business controls economy, centralization risk. - running dao websites. 10x. no secure ownership of hosting by DAO. - scihub. anyone can launch centralized. 0x combined delta: a blockchain for big datasets. open usage of data. 10x. ---- ## Proof-of-transfer A probabilistic protocol to notarise data transfer and bandwidth between two nodes. We have STARK's which are probabilistic proofs, but could we apply the same principle to passing messages? A hashlocked time contract (HTLC) scheme kind of functions this way - commit to locking some coins, the other node reveals the preimage to unlock them, and then there is an incentive to claim them. Perhaps you could apply this to networking - commit the hash of the message you will send, with a reward, send it, and as soon as the other node receives the full message, they have the preimage and are incentivised to claim the reward (during which you measure latency). https://hackmd.io/@liamzebedee/B1kZuzxk6?utm_source=preview-mode&utm_medium=rec The idea is that you run bittorrent over a "provable" networking substrate. The provability is probabilistic. All requests are deterministically satisfiable - ie. requests are for hashes, response are the preimages / the data which gives this hash. A random sample of requests are used to inform latency/bandwidth metrics, in a cryptoeconomic game similar to a hash-locked time contract. How do you measure bandwidth/latency securely in a byzantine context? We use a mixture of ideas from onion routing and atomic swap contracts. A few key insights: - we can use a hash-locked time contract to incentivise reporting the preimage of a hash. - bittorrent's protocol looks like this - client requests a chunk (hash), server sends the data (preimage). - a hash-locked time contract is a mechanism which can reveal the latency and bandwidth of a data transfer - since we can measure the start and resolution time in the contract. - unfortunately, a HLTC requires a trusted source of timekeeping. a blockchain is not granular enough (e.g. ethereum with 6s blocks, solana with 700ms blocks). - as such we introduce a relayer, which measures time using a VDF. - we want an **online interactive protocol**. a protocol being able to be run at any other point in time introduces attack vectors - ie. replay attacks, collude to report latencies in advance. - as such, every message is unique (nonce), anchored to public timekeepers (block hashes) - desirable goal: ---- do you want to distribute data around the world do you want to buy bittorrent hosting onchain? do you want to summon a bittorrent swarm do you want to buy hosting services for data? do you want to buy anonymous hosting for datasets? distribute clandestine data buy clandestine bandwidth dark fiber a cryptonetwork for data distribution dissemination services this is axon a protocol to summon bittorrent swarms to host datasets, on-chain imagine buying a .eth domain and uploading content to it, without installing any software here's the problem - where do you host media, datasets? arweave doesn't scale like bittorrent filecoin is unusable none of them guarantee speed axon does. buy your .eth domain, upload content to it, and pay for hosting
Last changed by  
 
Liam Zebedee
twitter.com/liamzebedee github.com/liamzebedee
107

Read more

Computational Data Markets

Problems this addresses:

9/15/2023
Scoring agency using LLM’s and simulated DM’s.

An LLM allows you to simulate human thought, as described in text.

9/14/2023
RFB: Detecting Ethereum RPC censorship programmatically.

UPDATE: I was wrong, Infura doesn't censor RPC reads! This post caught the eyes of Infura, and they set out and wrote a blog post which you should check out. Although, the party isn't over yet. The option to censor is still there unless we use secure RPC. Which is why I ended up building out this, check it out- https://github.com/liamzebedee/eth-verifiable-rpc Liam Zebedee (@liamzebedee). This is a spec, a request for either (1) grants or (2) builders. Please reach out on the Twitter thread / over DM's if you're interested in either. Introduction. Recently, Ethereum node providers like Infura/Alchemy started censoring parts of the Ethereum database from being read via the JSON-RPC API's. This proposal is to programatically detect this, by building a local EVM shim that verifiably loads state from a remote node during execution.

3/1/2023
The Crypto Book - table of contents.

Index for a book I'm writing. Write out a book.Explain how ZK-STARK”s work from the ground up (video/whiteboard).What is the anatomy of a STARK proof Explain how Cairo, VM, computers etc. work. Megathread deepdive: covers state machines, prover-verifiers, VM's, the cairo language, how STARK's work, arithmetization, the Cairo machine, computation compared with EVM (addition), public memory, memory holes, Cairo runner/bootloader Explain how recursive STARK’s are so powerful.

1/18/2023
Read more from Liam Zebedee
Published on HackMD