ETHGlobal Hackathon Idea:
0xBOTS.eth is an ENS-mediated protocol that enables web2 & web3 frontends to have lightweight compute-enabled distributed backends.
0xBOTS is a web-wide protocol that enables web3 or web2 frontends requiring CPU or GPU time to move beyond centralised backend compute resources. Current generation of IPFS- and Arweave-enabled dWeb frontends are tied down by backend requirements of servers if they intend to serve any data-oriented HTC or HPC content. 0xBOTS protocol is a security-enabled BOINC distributed-computing infrastructure built to provide decentralised and secure high-throughput computing to web3 (or web2) frontends. The communication and monetisation layers in 0xBOTS are mediated by Ethereum, specifically ENS and SIWE. In this prototype however, the monetisation layer is mediated by Lightning BTC Network to keep this hack Solidity-free and fun (writing a price oracle right now is not a priority).
Supply side: One entity identified by 0xBOTS.eth has compute resources in form of CPU or GPU idle time on a number of big and small devices ranging from servers to smartphones. 0xBOTS.eth is able to manage the compute resources on its devices using a BOINC (Berkeley Open Infrastructure for Network Computing) build residing on its centralised server. 0xBOTS.eth arranges the architecture in a way that 0xBOTS.eth.limo resolves to the frontend of the BOINC server. Moreover, subdomains
*.0xBOTS.eth map to as many devices as managed by the BOINC server. This mapping has no strict architecture and it is optimisable as a function of types of managed devices. 0xBOTS.eth.limo now searches on the web for opportunity to compute, hopefully in return for some cheap $ETH on L2 , or in this case, $BTC on Lightning Network .
Demand side: A website.xyz (web2 or web3) requires resources in form of compute time. It broadcasts a request for computation via the
.well-known URI or equivalent located at
https://website.xyz/.well-known/. In the broadcast JSON, metadata provides,
a) the URI of the code to execute,
b) arguments required by the code,
c) website.xyz’s backend URI
GET requests (
website.xyz/nonce, for example),
d) a random key string
STR to associate to the request, and
e) a flag (not a necessity but helpful for state verification).
Interaction: The supply and demand side meet when 0xBOTS.eth.limo finds a request to compute on
.well-known URI of website.xyz during its routine search for work. Once the request is confirmed to be active via the flag, 0xBOTS.eth.limo grabs a nonce from
website.xyz/nonce with a
GET request and sends a signed
POST request to
website.xyz/ along with a) the random key string
STR identifying the compute request, and b) URI where website.xyz can retrieve the computed output. In the prototype, we will showcase this communication using manual SIWE workflow in Metamask. This framework establishes the required communication layer necessary for the protocol. Needless to say, two additional layers - security layer and payment layer - will be implemented on top to ensure the validity of the computed output and settling payments respectively. In this prototype, we will use ‘integration checks’  for security and BTC Lightning Network for broadcasting and receiving payments via the LNURL-(w/a/p/c) infrastructure (to confuse maxis on either side ). In the final protocol, settling on Ethereum L2s via a price oracle is probably the ideal solution.
 Integration Check: It refers to validating the computation by pre- or post-computing a small random subset of the computation to match against the incoming results from the computation provider 0xBOTS.eth
Used technologies: IPFS/IPNS, BOINC, SIWE, ENS, Metamask, LN-BTC.
Demo mirrors: 0xbots.eth.limo | work.inpl.one
Showcase: 0xBOTS · ETHGlobal Showcase
GitHub: GitHub - sshmatrix/0xbots: ENS-mediated protocol that enables web2 & web3 frontends to have lightweight compute-enabled distributed backends
I like the idea you have with this protocol especially since it is bcL1 (Layer 1 becomes confusing when also describing the 7 Layer OSI Model) agnostic:
"Ethereum (Decentralized/Distributed) still runs on the Application Layer of the OSI Model. Maybe clarifying the nomenclature (jargon) to something like this: bcL1 // bcL2 (blockchain Layer Two) or someone else can propose something that is different. "
The greatest asset that this “Universal_Web-Protocol” provides is in it’s integration with Bitcoin’s Lightning Network which can leverage it’s utility within Twitter and provide additional leverage towards its utility and adoption into Web 3 FinTech framework.
Adding a parity bit for state verification could speed up total processing time while reducing the load on network utilization.