Developer Use of the DDB

Smart Contracts vs. Stored Procedures: In NCOG, smart contracts can be written to use the DDB for data storage. A special kind of smart contract – think of it as a “database contract” – defines the schema (tables) and stored procedures that can be invoked. Developers write these stored procedures in a supported language (SQL/PLpgSQL for now, potentially others in the future) and deploy them on the blockchain. This defines the permitted operations on the data (for example, a contract might define a table Orders and procedures placeOrder, updateOrderStatus). Because the schema and procedures are on-chain, everyone can inspect them (ensuring transparency of business logic). 

To interact with the database, a user or dApp sends a transaction calling a stored procedure in the database contract, much like calling a function in a conventional smart contract. The difference is behind the scenes – this call triggers the dual consensus flow described above instead of pure EVM-like execution. From the developer’s perspective, however, it’s straightforward: they use an API (e.g., an SDK or RPC call) to invoke the stored procedure with parameters. The platform ensures the call either commits (with strong consensus) or aborts. 

Querying Data: Reading data from the DDB does not require sending a blockchain transaction (unless the read must be on-chain verified). A dApp can query any DDB validator node for the data it needs. Because all DDB nodes replicate the state, a query like “SELECT \* FROM Orders WHERE user=42” can be answered by a single node’s database. This is much more efficient than, say, scanning a blockchain’s state via RPC. For trustless verification, a DDB node could return the data along with a Merkle proof or state hash signed by the network, tying it to the last block. Plans include providing such proofs to clients who want to verify data against the blockchain’s recorded state. But often, if a user is querying their own data, they may trust a couple of different validators and compare answers. 

Consistency Guarantees for Developers: A very important aspect is that the blockchain and database are interconnected. If a blockchain transaction involves both a token transfer and a database update, they can be done in one atomic operation: e.g., a stored procedure could include a token debit as part of its logic (the database contract can call system functions to transfer tokens or require the caller to attach payment). This ensures that business logic that spans assets and data can be unified. The dual consensus guarantees that either both the token state and DB state change, or neither does. 

Using the DDB vs. Traditional Smart Contracts: Developers can choose to keep simpler logic in traditional smart contracts (running in NCOG’s VM), which use the blockchain’s built-in key-value storage, or to leverage the DDB for complex data. The DDB is most beneficial when you have large tables or need to do complex queries (like analytics, joins, text search) that would be infeasible or too expensive in a normal smart contract. For instance, a decentralized Twitter clone could store tweets and profiles in the DDB (allowing efficient query by hashtag or user), rather than trying to cram that into on-chain events. Meanwhile, it could use regular smart contracts for token interactions (tips, etc.) that don’t need the database. NCOG Earth Chain supports both paradigms and links them. 

In summary, NCOG Earth Chain’s DDB feature is a powerful advancement that brings enterprise database capabilities into the blockchain realm. It does so with a carefully engineered consensus workflow to preserve integrity and performance. Developers can build dApps that handle far more data on-chain than ever before, with the ease of SQL and the confidence that the blockchain validators are keeping the database honest. All changes are transparent and auditable (every DB transaction leaves a hash and endorsements on-chain), which could be invaluable for compliance and auditing in e.g. supply chain or financial applications.