People tend to overestimate how easy it is to create a blockchain.

Just because you were able to deploy a network doesn’t make you an expert on blockchain. As a matter of fact, even an intern can do it in minutes. Here, try it.

You know what else is easy to deploy? A webpage.

Creating a blockchain is easy, and you can do it at zero cost and effort for as long as you don’t care about the design and spec of your network.

Understanding the engineering constraints to design a secure and functional blockchain architecture already takes real knowledge and skills. That’s only to get the theory right. Implementation is another thing. Yet somehow all these noise led to discussions about neither theory nor implementation. If you ask me, that’s… not a great sign.

Anyway, maybe danki iz just impatient 😌⚙️

From the cryptonative perspective, “using blockchain” means institutions forking their own version of the OP Stack and pretending it’s decentralization and transparency.

This is absurd.

Public chains like Ethereum, L2s, and alternative L1’s (which are privately owned chains with a wee more nodes) are engineered for open participation, fully transparent states, and global settlement.

This design is beautiful for permissionless systems… but is horrible for enterprise or government environments. It’s also why I don't recommend dumping our data and processes straight to a public chain for the sake of verifiability. Public chains are also perfect adversarial environments and are an excellent mass surveillance tool.

So, should we use a database instead? Private chain?

Maybe. You decide, compadre. But that leads us to…

There are three challenges facing blockchain use for enterprise:

1. Privacy — enterprise data cannot be globally visible by default

2. Custodiality — access must be controlled and enforceable

3. Interoperability — systems must remove data siloes and permissionlessly extend, compose, and integrate with others. Bonus if it’s compatible with other global digital ecosystems.

And since many of you are thinking of the recent “Philippines explores blockchain for transparency” saga…Yes. Let’s design around that.

There are a few viable options, each with tradeoffs. But first:

“Can’t we just use a shared, append-only database?”

Using a database is actually great, but here’s why you need more than that:

1. For governments and businesses, storing and governing user data is a liability

Unless you’re selling data to advertisers or training AI models, storing personal data for millions of people is expensive, and dangerous because it makes you a target. Blockchains allow self-governed data through private keys. Databases + PKI can’t do that.

2. Human-operated systems is not the future of France

Humans are slow and prone to mistakes. The less manual handling, the fewer middlemen, the fewer signatures and offices, the more honest and efficient a system becomes. Blockchain provides neutral, programmable rails for automated coordination at scale.

3. Data permanence matters

Multiple diverse validators (even in a permissioned consortium) means durability and accountability. Combined with public anchors, it makes any form of cover-up difficult.

“Okay Danki, what are our options?”’

There’s no single “best architecture”, only tradeoffs.

The only rule is that we design around the constraints.

Different institutions will pick different points in the spectrum based on:

• budget

• threat model

• compliance requirements

• risk appetite

• engineering maturity

• and how allergic they are to devops

So here are your options:

You use Hyperledger Fabric or Corda, throw in a few millions, spin up your validators, and create your own enclosed world.

Great if:

You have big money and want full control of the network, automation via smart contracts, and internal auditability of your processes.

Advantages:

• privacy by default

• no strangers validating your data

• smart contract automation

• internal accountability

Downsides:

• devops hell (validators, nodes, uptime, monitoring)

• zero decentralization

• zero interoperability with public chains ergo, zero public accountability

• becomes a glorified distributed database

• if you’re poor, do not attempt

You work with Hyperledger Besu or Polygon Miden/Supernets (they keep changing the name). Either way, your private chain keeps the data private while pushing public data to a public chain for accountability.

Great if:

You want a private chain but still need to prove things publicly. And you also want compatibility with global public-chain ecosystems. And you have more money to spend than the person choosing Option 1.

Advantages:

• privacy preserved

• auditability retained

• no mass surveillance

• you choose what becomes public

• interoperability with the public chain ecosystem (Ethereum or Polygon)

Downsides:

• gas fees still exist

• adversarial actors can still analyze data if insecure implementation

• devops still exists

• even worse for the budget. because now, you’d have to pay gas to the public chain on top of your private chain expenses.

Note:

pls don’t be cringe.

Publish hash commitments, NOT your entire dataset through NFT metadata. Nobody wants to accidentally leak the entire payroll onchain.

Instead of building a private chain, you do all the transactions on a special, institution-owned hardware (a physical atm machine, computer, or vault). Assume it’s an impenetrable enclave that nobody can tamper with. Post attested results onchain.

Great if:

You want private transactions but want to post proofs publicly onchain. Security matters less than speed and cost efficiency. Probably not as expensive as options 1 and 2, but you have to trust a lot of vendors.

Advantages:

• data stays private

• very small onchain footprint

• fast and relatively cheaper

• conceptually simple, even old people can understand it

Downsides:

• you have to trust the manufacturers

• you have to trust that it can’t create a signature if it’s tampered

• enclave vulnerabilities exist (and have been exploited)

• vendor lock-in

• might be inconvenient for users to be physically present to use your system

It’s “privacy by hardware,” not privacy by design. Still valid, but choose wisely.

You create an identity system. Keep your database. Keep your backend chaos. Keep your entire Frankenstein architecture.

Add a module that generates zero-knowledge proofs whenever something important happens:

• bids

• requests

• balance updates

• awarding

• fund releases

Maybe even partner with banks to allow consented creation of proofs for certain accounts. Proofs get published publicly onchain. Data stays private. Verification can happen publicly or privately.

Great if:

You want to modernize slowly. You don’t expose the data to the whole globe but only to a select population who’s concerned. You just commit to its existence and integrity. You’re not ready for blockchain’s interoperability and automation, but you somehow have access to a rare cryptid dat is a ZK Engineer.

Advantages:

• raw data never touches the chain

• cheap on L2s (₱20 or less per proof)

• public accountability without exposing internals

• works with your current databases and workflows

• incremental modernization

Downsides:

• ZK engineers are costly and are difficult to find

• ZK circuits can be fragile if done incorrectly

• It’s a little slow to create proofs, though not that bad

• side-channel leaks are still possible, SNARKS aren’t quantum safe yada yada…

• requires actual cryptographic understanding and discipline

• if you don’t design your architecture to be interoperable, then it won’t be

I’m biased. But unless we invest in local cryptographic engineering education, we’ll be importing foreign crypto talents to the tune of $300k/year per engineer.

So if you actually want a Philippines that can build privacy-preserving national infrastructure… Maybe– JUST MAYBE – support Danki’s Cipher PH next year. We’ll want Filipino ZK wizards instead of paying Silicon Valley rent.

Hekk… that’s a tough one.

You could blend everything. You could phase it out. You could even throw darts at a diagram and see what sticks. Very on-brand for us, tbh.

If you’d ask me: Start with onchain proofs. They’re small, manageable, and low-drama. Private chains and DIDs can come later when everyone’s blood pressure has stabilized.

But I’ll favor whichever path won’t collapse under the weight of Filipino bureaucracy + budget + politics + lack of technical crypto talents.

The one that fits our constraints, our budget, our reality… not the fantasy someone saw on a conference slide deck. And definitely not the slapdash horrors that were only created out of spite.

We just need to build carefully, add tech where it actually helps, and avoid swan-diving into the deep end without floaters.

Nice and steady. Good math, low chaos. 🐴💛✨

People tend to overestimate how easy it is to create a blockchain.

Just because you were able to deploy a network doesn’t make you an expert on blockchain. As a matter of fact, even an intern can do it in minutes. Here, try it.

You know what else is easy to deploy? A webpage.

Creating a blockchain is easy, and you can do it at zero cost and effort for as long as you don’t care about the design and spec of your network.

Understanding the engineering constraints to design a secure and functional blockchain architecture already takes real knowledge and skills. That’s only to get the theory right. Implementation is another thing. Yet somehow all these noise led to discussions about neither theory nor implementation. If you ask me, that’s… not a great sign.

Anyway, maybe danki iz just impatient 😌⚙️

From the cryptonative perspective, “using blockchain” means institutions forking their own version of the OP Stack and pretending it’s decentralization and transparency.

This is absurd.

Public chains like Ethereum, L2s, and alternative L1’s (which are privately owned chains with a wee more nodes) are engineered for open participation, fully transparent states, and global settlement.

This design is beautiful for permissionless systems… but is horrible for enterprise or government environments. It’s also why I don't recommend dumping our data and processes straight to a public chain for the sake of verifiability. Public chains are also perfect adversarial environments and are an excellent mass surveillance tool.

So, should we use a database instead? Private chain?

Maybe. You decide, compadre. But that leads us to…

There are three challenges facing blockchain use for enterprise:

1. Privacy — enterprise data cannot be globally visible by default

2. Custodiality — access must be controlled and enforceable

3. Interoperability — systems must remove data siloes and permissionlessly extend, compose, and integrate with others. Bonus if it’s compatible with other global digital ecosystems.

And since many of you are thinking of the recent “Philippines explores blockchain for transparency” saga…Yes. Let’s design around that.

There are a few viable options, each with tradeoffs. But first:

“Can’t we just use a shared, append-only database?”

Using a database is actually great, but here’s why you need more than that:

1. For governments and businesses, storing and governing user data is a liability

Unless you’re selling data to advertisers or training AI models, storing personal data for millions of people is expensive, and dangerous because it makes you a target. Blockchains allow self-governed data through private keys. Databases + PKI can’t do that.

2. Human-operated systems is not the future of France

Humans are slow and prone to mistakes. The less manual handling, the fewer middlemen, the fewer signatures and offices, the more honest and efficient a system becomes. Blockchain provides neutral, programmable rails for automated coordination at scale.

3. Data permanence matters

Multiple diverse validators (even in a permissioned consortium) means durability and accountability. Combined with public anchors, it makes any form of cover-up difficult.

“Okay Danki, what are our options?”’

There’s no single “best architecture”, only tradeoffs.

The only rule is that we design around the constraints.

Different institutions will pick different points in the spectrum based on:

• budget

• threat model

• compliance requirements

• risk appetite

• engineering maturity

• and how allergic they are to devops

So here are your options:

You use Hyperledger Fabric or Corda, throw in a few millions, spin up your validators, and create your own enclosed world.

Great if:

You have big money and want full control of the network, automation via smart contracts, and internal auditability of your processes.

Advantages:

• privacy by default

• no strangers validating your data

• smart contract automation

• internal accountability

Downsides:

• devops hell (validators, nodes, uptime, monitoring)

• zero decentralization

• zero interoperability with public chains ergo, zero public accountability

• becomes a glorified distributed database

• if you’re poor, do not attempt

You work with Hyperledger Besu or Polygon Miden/Supernets (they keep changing the name). Either way, your private chain keeps the data private while pushing public data to a public chain for accountability.

Great if:

You want a private chain but still need to prove things publicly. And you also want compatibility with global public-chain ecosystems. And you have more money to spend than the person choosing Option 1.

Advantages:

• privacy preserved

• auditability retained

• no mass surveillance

• you choose what becomes public

• interoperability with the public chain ecosystem (Ethereum or Polygon)

Downsides:

• gas fees still exist

• adversarial actors can still analyze data if insecure implementation

• devops still exists

• even worse for the budget. because now, you’d have to pay gas to the public chain on top of your private chain expenses.

Note:

pls don’t be cringe.

Publish hash commitments, NOT your entire dataset through NFT metadata. Nobody wants to accidentally leak the entire payroll onchain.

Instead of building a private chain, you do all the transactions on a special, institution-owned hardware (a physical atm machine, computer, or vault). Assume it’s an impenetrable enclave that nobody can tamper with. Post attested results onchain.

Great if:

You want private transactions but want to post proofs publicly onchain. Security matters less than speed and cost efficiency. Probably not as expensive as options 1 and 2, but you have to trust a lot of vendors.

Advantages:

• data stays private

• very small onchain footprint

• fast and relatively cheaper

• conceptually simple, even old people can understand it

Downsides:

• you have to trust the manufacturers

• you have to trust that it can’t create a signature if it’s tampered

• enclave vulnerabilities exist (and have been exploited)

• vendor lock-in

• might be inconvenient for users to be physically present to use your system

It’s “privacy by hardware,” not privacy by design. Still valid, but choose wisely.

You create an identity system. Keep your database. Keep your backend chaos. Keep your entire Frankenstein architecture.

Add a module that generates zero-knowledge proofs whenever something important happens:

• bids

• requests

• balance updates

• awarding

• fund releases

Maybe even partner with banks to allow consented creation of proofs for certain accounts. Proofs get published publicly onchain. Data stays private. Verification can happen publicly or privately.

Great if:

You want to modernize slowly. You don’t expose the data to the whole globe but only to a select population who’s concerned. You just commit to its existence and integrity. You’re not ready for blockchain’s interoperability and automation, but you somehow have access to a rare cryptid dat is a ZK Engineer.

Advantages:

• raw data never touches the chain

• cheap on L2s (₱20 or less per proof)

• public accountability without exposing internals

• works with your current databases and workflows

• incremental modernization

Downsides:

• ZK engineers are costly and are difficult to find

• ZK circuits can be fragile if done incorrectly

• It’s a little slow to create proofs, though not that bad

• side-channel leaks are still possible, SNARKS aren’t quantum safe yada yada…

• requires actual cryptographic understanding and discipline

• if you don’t design your architecture to be interoperable, then it won’t be

I’m biased. But unless we invest in local cryptographic engineering education, we’ll be importing foreign crypto talents to the tune of $300k/year per engineer.

So if you actually want a Philippines that can build privacy-preserving national infrastructure… Maybe– JUST MAYBE – support Danki’s Cipher PH next year. We’ll want Filipino ZK wizards instead of paying Silicon Valley rent.

Hekk… that’s a tough one.

You could blend everything. You could phase it out. You could even throw darts at a diagram and see what sticks. Very on-brand for us, tbh.

If you’d ask me: Start with onchain proofs. They’re small, manageable, and low-drama. Private chains and DIDs can come later when everyone’s blood pressure has stabilized.

But I’ll favor whichever path won’t collapse under the weight of Filipino bureaucracy + budget + politics + lack of technical crypto talents.

The one that fits our constraints, our budget, our reality… not the fantasy someone saw on a conference slide deck. And definitely not the slapdash horrors that were only created out of spite.

We just need to build carefully, add tech where it actually helps, and avoid swan-diving into the deep end without floaters.

Nice and steady. Good math, low chaos. 🐴💛✨