DB3 | Devpost

Track

Web2 to Web3 – bootstrapping “traditional” apps and tools on blockchain

Inspiration

Almost all decentralized networks heavily rely on centralized providers to host and access their data. NEAR is no exception. For truly decentralized systems we need to think about how SaaS databases would look like in a web3 economy. How can you trust responses are correct, queries are not censored, and data is available at the latency your dapp requires?

What it does

DB3 is a decentralized web3 database network where service providers get paid for query execution. DB3 is permissionless, i.e. anybody can deploy, host, discover and query databases. Developers implement database schemas + logic and deploy them as smart contracts. Hosts choose which databases to run based on interest and expected traffic. Hosts must lock a slashable security deposit and (co)-sign query results to prove correctness. Users attach fee payments to queries and send them directly to a set of hosts for execution. On successful and timely execution, the protocol pays out collected fees to hosts and a royalty share to developers.

How we built it

Our goal in this hackathon is to develop one or multiple smart contracts on NEAR for registering databases and hosts, handle their security deposits, manage query fee payments and fee payouts. We chose near-js-sdk and opted to build a single contract with all functionality in once place to save time. It's sufficient for a POC, but probably not performant for a production setup. We created a small frontend in JS that has user flows for our 3 target groups, database developers, database hosts and query users so they can see their registrations and interact with the DB3 protocol. There's also a database node server implementation in Go and a small simulation client in Go that sends mock queries with attached fee payments.

Challenges we ran into

Building an initial contract in Typescript was fast given the extensive documentation, but there's a few issues with the JS SDK that are not well explained and quite a errors are not caught by the Typescript compiler. Issues we encountered

JS/typescript gets quite verbose, unreadable and buggy when you work with containers because you lose type info for keys and values and have to explicitly cast using as typename which is error prone
you cannot store maps inside maps
as workaround we used flat maps with complex keys (concatenated strings with separators) like you would do in Redis, but there's no scan() or prefix match to filter for relevant key prefixes either
call arguments have to be objects (without {} there's no warning, the call just does not work as expected)
container types lack functionality (there is no contains() or has() method for maps)
when Go SDK?

Accomplishments that we're proud of

POC works.

What we learned

Using JS for smart contracts may get you quick results initially, but due to issues explained above it will not become our go to method for building contracts. It's interesting that you can deploy new code if storage layout doesn't change. Helped us quite a bit when navigating the JS quirks. Maybe Rust is better but we are not experienced with it. It would be awesome to have a Go SDK.

What's next for DB3

We will continue to work on building a full database node that can host multiple databases as well as tooling to help developers write databases together with their source feed & ETL logic in languages that compile to WASM. DB3 is supposed to become a cross-chain database network, so we are exploring different ways of handling fees and deposits. At scale, DB3 requires a payment and vote settlement rail with an execution model that is natively parallel so that traffic on unrelated databases is not bottlenecked by transaction serialization and global block validation. We're very much looking forward to observing how Near scales in the future.