|Blockchain, keeps fidgeters occupied, not bothering others|
The talk was mostly about the general concept, general need, and generally how blockchain would help. Nothing shocking, but it is useful to hear it from people who have done it. The panelists were Dr Mark Cotteleer from Deloitte, Chris Kirchner of Slync, and Paul Biwer from Biwer & Associates. The guest speakers were from organizations involved in actual use (pilot) in the Food supply-chain, and in package shipping.
The first caution was that the larger the network of supply chain participants, the more complex; the more complex the harder to make a working system. Hence the very narrow usecase focus in the package shipping usecase to track packages given into their control. In this case the speaker indicated there were about 5 participants, so I am guessing these would be a few out-sourced transport or handlers.
What data should go into Blockchain vs managed classically?I spoke to them afterwards. Given that they have experience, I asked if any patterns have emerged as to what data actually goes into the blockchain, vs what data is managed in classic ways. Looking for patterns from experience. I got a very strong answer: "As little as you can get away with goes into the blockchain". One reason given was that the more you put there, the more fragile the system is to improvements. Once data is in the blockchain, it is there forever. It is far easier to later add an element of data that wasn't previously shared. But once something is there it is permanently there.
Permissioned blockchainsThey are both using Permissioned chains, where a small subset are authorized to add to the chain, and where a subset of them have validation and counter-signature responsibilities. The validation requirements are use-case specific, and data accessibility specific. Where little data is on the chain, little can be validated. Where that data approaches nothing, the only validation is the date/time stamp freezing that data in time. So clearly there is a balancing task of putting enough into the chain to make validation valuable, but not so much as to make the solution fragile or dangerous.
Danger of public accessibilityI then approached the topic of negatives. That is to say, the blockchain use-case will work fantastically when everything is running smoothly and everyone does their duty properly; but the reason a blockchain is used is because at some point someone will slip up and something bad will happen. It is at this point that the blockchain is used to determine from something bad happening, back to who caused that bad thing. Without this need, there is no need for blockchain. So, it by definition will happen.
The answer I got was… hmmm, never thought of that…
The big Aha moment
- Start with a use-case that has fewest actors to keep it as simple as possible. You can always add actors later.
- Design each blockchain to handle the right audience and active participants. You can always add more functional chains later.
- Put as minimal data into the blockchain as you can get away with for the use-case need. You can always add more data elements when they are found to be critical.
- Augment blockchain functionality with classic data management methods. Don't abuse the blockchain, use it carefully.
- Think through abuse scenarios up front. Happy-path is nice, but not why you are designing to use blockchain.