Tips for Enterprise Blockchain Deployment
A brain dump of learnings I’ve sponged up over the last four years
Taking the leap to enterprise grade software is hard. And it’s even harder with a technology that is hitting its adolescent phase, deciding what it wants to do with its life, who it’s going to date, where it’s going to live and what it’s going to apply itself to. If it was easy, everyone would be doing it, and its difficulty is one of the reasons why blockchain is yet to hit mass adoption.
Moving to enterprise requires a change in mindset and approach from fast paced innovation environments to new priorities such as availability, usability, resilience, compliance and critical support, without losing sight of the problem it was built to solve in the first place. I’ve decided to compile and share a list of learnings from my own experience and that of a few others who have done this successfully around the world.
FYI Many of these relate to Ethereum as that’s what I’m most familiar with.
In no particular order…
Minimise the use of the ledger for menial computation
Executing functions in a smart contract is relatively slow and expensive when compared to something like an Amazon EC2. If it’s necessary, do it, but think about what that will look like when scaled. Optimise computation intensity and cost reduction where you can, and don’t create a high latency terrible user experience for the sake of saying that you’re using a smart contract.
Your users probably don’t care about your shiny EVM, but they will care if it takes ages to get anything done.
Comply with confidentiality
It can sometimes feel like the utopian vision of blockchain is for full transparency of data sharing, but in the regulated world we live in that is gradually empowering the consumer this might not be the best endgame. Get to know confidentiality requirements and use the technology to your advantage to tread the fine line between empowerment and exposure.
Keys are king
Keep them safe; digital copies in a cloud vault, physical copies in a physical vault, Italian Job-style but one that can resist the bloody doors getting blown off. Don’t let people swamp your key management procedures (digital and physical) otherwise you’re putting them at risk.
Get it right once or get it wrong forever…
Audit your code before you deploy! This can be done automatically and periodically with a tool like MythX, through online tools like EY Smart Contract testing or manually (no name drops, I’m not paid to advertise).
Don’t go broke, and I don’t mean your company (though that’s important too)
Keep your wallets and contracts well stocked on gas. You wouldn’t set off on an epic roadtrip on one tank of fuel without at least knowing where gas stations are, so don’t do the same with your platform otherwise you risk getting stranded with a search party of angry clients out to get you. Get a faucet on point.
Get a queue jump pass
I.e. monitor gas prices and raise yours if needed. You don’t want to be causing unnecessary latency because you’re too stingy on fees…
Design for interoperability
It’s a risk averse, arguably slower bet hedging approach, but don’t go all in on one protocol without even considering or semi-regularly checking others. Last thing you want to do is stake your whole enterprise system on a layer that ultimately can’t talk to anything else.
By all means choose one now but stay fickle and don’t chain yourself to an unsteady ship, or even worse, a private blockchain.
It’s not mined until it’s mined
Keep one eye on transactions until they are confirmed, and use your other eye to keep facing forward otherwise an unmined transaction can bite you in the back down the line.
Keep your nonces in check
Batching transactions is great, but if done wrong it can throw your nonces out of line, especially for off-chain transactions. Keep a meticulous record of this otherwise a well organised list will quickly start to look like a game of pick up sticks.
Think about why you decided to use blockchain in the first place
Hopefully it wasn’t because it sounds cool. Really assess the benefits of DLT, and design an architecture that maximises the use of more mature systems to minimise the potential issues of scalability and transaction throughput that blockchain platforms currently face without completely sidestepping your reason for using it. It’s ok to build something with a roadmap to increasing DLT usage as the tech layer matures; no one is forcing you to go full distributed utopia from day one if it compromises on getting out solutions that solve problems.
Blockchains have the potential to fundamentally change the way parties transact with each other, and ergo the economy as a whole. But Rome wasn’t built in a day, so it will take time to get things right before that future is fully realised. Hopefully the tips above will help somewhat with that.