In reference to this excellent article published on Medium (picture credit https://stephenblackford.blogspot.com/2013/01/the-wachowskis-cinematic-legacy.html)
It's clear, Crypto payment settlement networks have come a very long way in a very short period of time, leapfrogging SWIFT and IBAN features.
That said, we still have a very long way to go for cryptos to be widely accepted and put in use by the general public.
Crypto concerns like #Chainlink (A Multi-chain gateway) & #IOTA (Distributed Public Ledger focused on IoT) very much see the need for Oracles as essential mandatory elements of their next generation crypto payment network capabilities, adding another layer of the "Security Onion" which, if implemented properly, will certainly create more prospective user trust and faster adoption of cryptocurrencies, sooner rather than later.
Incentivized Trust: Grow Crypto Adoption Faster with Great Oracle Designs...
What is the next "Bellweather" software design factor we need to leverage in order to drive the level of acceptance another order of magnitude higher with the general public?
Per the article, it comes down to embedding "incentivized trust" into the solutions we are building in the crypto world.
The way forward is indeed, as Julien Thevenard
of Fabric Ventures points out https://medium.com/fabric-ventures
the Integration of Decentralized Oracles into the crypto payment networks which are "incentivized" to be trusted.
Oracles, a Mandatory part off the Crypto "Security Onion"
Oracles represent another "security onion" layer of "middleman" security, which can create new "attack surfaces". To make sure these new surfaces are safe, having the payment network provide a monetary incentive or reward to the oracle, makes perfect sense.
Where the "Oracle collective" securing transaction on the crypto network is doing a good job, rewards are given, conversely a charge to the Oracle collective and or individual Oracle "bad Actor" in subtracted from the oracle balance(s) and in the worst case the offending oracle is placed on probation or, even banned (for a period of time, or even for ever) for repeat occurrences within a given time frame.
When accountability in financial payment systems (ie - did transaction get there on time and in sequence (settle correctly based on the terms of the transaction, was the amount correct, were there no duplicate "double spend" transactions allowed, did the transaction behaviour match the rules of the smart contract, etc..,) is rewarded or extracted immediately in the form of credit or debit to the Oracle's own "wallet", without a judge and lawyer or pair of accountants (battling it out) in the way, and the penalty matches the transgression, "financial justice" is served, in near real time.
That type of accountability in near real time, with much lower transaction overheads (the small per transaction rewarded added or deducted from the Oracle's "wallet") speeds the velocity of money in any economy to help grow more efficiently with better returns to the stakeholders.
Designing an Oracle for your Crypto payment System?: Start with Test Case "Expected Results"
The use case "depth and breadth" of the Oracle created to boost the trust and reduce the risk of the crypto payment/settlement system needs to be validated by an even broader primary, secondary and exception set of test cases with well defined, clear and concise "black and white") metrics governing the pass and fail "validation" of the Oracle logic controlling the payment as a payment/settlement "gateway" are paramount.
Too many designers of crypto payment systems today, like in the past, when they build CRM, ERP and Fintech systems, start writing code without understanding the primary, secondary and exception use cases.
The result? Lots of security transgression during normal operation, which has "ballooned" the size of the Security software market beyond belief.
Write shitty code? Grow the Security Software Market. It's a "Catch 22" with each market feeding and growing off the other, creating ever more expensive systems with minimal chance of an investor return.
The big question any investor or VC should be asking themselves financing an Oracle integration into their crypto payment network is:
Can an 18 to 35 year old "C++ or Java" declarative language developer, leading a dev/tst/ops team as a CTO or VP of Engineering/Development, really be trusted to get the design of the Oracle right the first time?
IMO The likelihood of such effective leadership happening in such circumstances as describe above is "slim".
Here is why:
What is more important to ensuring good Oracle design is the experience of the developer leading the team, CTO or otherwise, the title does not matter.
That experience is not about the minutia of the a programming language and what it can or cannot do.
Really valuable staff experience is framed in reality, when it comes to building an Oracle, by the team's collective understanding of the business and operations logic. Thi is best described in their understanding (written down) in the form of expected outcome "Test case results and metrics" used to determine pass/fail" and how they drive the clear definition of the Oracle use cases which make up the requirements, describing the various actors involved in the process and related systems and methods used, in "Plain Language", so the developer/Test & devops teams assigned to build, validate, deploy and operate the Oracle can be trusted to get the job done on time and on or under budget and within scope, BEFORE they write or adopt a line of code.
So where are all the adults leading the way? I mean developers with "tech chops" who really have been there, done that.
In the really good companies building break thru tech, Top 30 (by market Valuation) crypto companies like #Brave/BAT, #Iota, and a few others were led , right from day one, by serious experience technical people with grey hair and or no hair ( or a good hair colouring job :) ).
And the results are now showing with huge advances for example, #Brave #BAT and #IOTA are making with real clients making use of their tech in their respective markets to solve real problems, generate new wealth and improve the overall end user experience of transacting at much lower cost, safely, doing it "at scale" (lot of transactions/second).
"Me too" developments, the real "copycats" or "repeaters of repeaters" out there, tend to add little beyond what these big crypto break-thru companies are offering with ever growing adoption by businesses (big and small) at large. Most leaps forward in the crypto space today are evolutionary improvements, it is the speed of these "evolutions" taking place which can be worrisome for the risk averse, the general population at large. Earning trust of the masses and the VC and investor class is important, however , per my previous post, at the end of the day, "If grandma can't use it, well not many can or will use it." very much applies in the crypto payments space. :)
As a result come late 2019, more and more VCs lately are NOW busy evaluating, filtering and engaged is discounted arbitrage buying/selling/swapping IP and teams wholesale in the crypto space after ICO funds have dwindled and Market Cap numbers are way down for most crypto plays post "December 2017) . VCs are busy coercing mergers into other teams and in some cases shutting down and "wiping team positions out" partially or completely for poor and even non-performance (read scams) , separating the Crypto "wheat from the chaff".
ORACLE DESIGN TIPS: Keep Scope of Development, test and Devops within the "Composite" Team's Core-Competencies
A high value (crypto) Oracle design requires a reasonable period of time FOR THINKING, powered by really smart "experienced" people who have been through many trials and errors learned extracting Quality out of their solutions during the development/test and devops journey taken on the way to a successful operational solution launch (which actually gets used right away and often by the target market)
Great development, test and devop "composite" teams extract quality out of the development, test and operational deployment processes by properly and collectively managing the "Scope" of their software releases to match and stay within the skill levels (core competencies) of the resources they have on hand in "Make" mode, coupled with doing a 150% thorough job of "vetting" "buy/adopt" decisions which these days, means integrating 65-85% "open source" code integration into their "value add" crypto payment solution.
One of the collective team's bigger questions these days in crypto?:
"Is that open source code properly tested for security, performance scaling, quality of documentation, team commitment, competitive relevance, etc..?
Adopt the wrong mix of open-source, not necessarily properly designed, developed, tested , documented and supported by an active community and, IMO you are headed, sooner rather than later, for a high bug count, which will rapidly consume your cash runway with a higher burn rate than expected. That "rapid burn" means the CEO/COO pair the VCs/investors have 'hired' as part of the investment will be out hunting for cash earlier than expected, or all the time, and that my friends, is a BIG warning signal. Black Duck (Synopsis now) and WhiteSource are couple of "paid" open source management tools which help out and go beyond what Git, Github, Gitlabs and Bitbucket et al provide, to help team's better qualify the risk of what they are getting into (functional capabilities, legality, amount of effort, quality of community, velocity of project, etc..). Both are worth a look.
Driving great Oracle design into new and existing crypto payment networks with Test Case Expected Outcomes: Mandatory.
Ok those in the know, know this is the only way to go.
So a few questions help guide us in the right direction toward Great Oracle design:
What do good test cases look like?
For the "buy" decision of adopting existing open source: Is there an automated test framework available and does it work well, ie- is it equipped with test cases and test metric pass/fail metrics which make sense?
Does the open source "adoption" come with
B. "Codeless" Test framework (see Leapwork.com to learn more about that).
Test Cases" Get your Oracle "expected results" defined properly up front before you write (or adopt) a line of code.
A. Categorize first, your sets of expected outcomes, (a few categories listed below to get you started)
- Security (Attack Defense, multi-sig admin control, etc..)
- Performance (scale to transaction volume, across different payload sizes, etc..)
- Visibility (logging, replay of logging, analytical capabilities, etc)
- Chain of Custody (proof of, )
- Documentation (Say what? yup, very important to test documentation to various target audiences, technical, semi-tech and biz, ops literate audiences)
B- Evaluate your Resources, in detail
- Team Expertise (relevant to targeted dev, test and ops tech environment (language, supporting dev and test tools)
- Expertise Relevance given Solution Test and Development Challenge
- Team Experience (Biz and ops processes, success in delivering similar/same beasts, be tough here, this is where things go wrong BIG TIME)
C. Compare: do a "diff" and be really critical
- across the categories you create (as above)
D. Define the "Gaps" between "make" capability and "Buy/Adopt/Sub contract out" : Stick to your teams's core competencies
- What's missing what do we need,
- How much do the "missing parts" cost
- Degree of difficulty, how long to add in the missing parts, what additional resources and processes are needed to make it happen
- amount and quality of training required to close the "gaps"
E. "Cut to the Chase": Avoid Paralysis by Analysis, Spec and Phase your Oracle's Feature Scope in "doa-able Chunks" in realistic time frames
Oh yeah realistic time frames, whose estimates do you believe, the developers and programmers? Nope you believe the Testers, and the Dev ops guys.
Yeah the developers get a vote, record it, and see how close they come to actual results, this develops a layer of trust and helps with the make vs. buy/adopt decision.
F. Design your Oracle's high Value Functions by clearly describing Expected Outcomes as Test Cases with Metrics, then create:
- Primary Use Cases - Day to Day Normal "In Scope" Real time Functions of the Oracle ( Normal transaction operation behaviour & expect user audience results)
- Secondary Use Cases - Add Expected Recurring Event & State Functions of the Oracle ( Grow, Move, Upgrade, Remove or Replace a function, etc..)
- Exception Use Cases - Add Unexpected , Random or Regular Events and Respnse of the Oracle (Attacks, Intrusions, Unexpected Shutdowns, etc..)
to build the solution Requirements Doc AND an Acceptance Plan based on Test Case Metrics (pass/fail & specific target behaviour, ie- TPS Transactions per Sec.)
E. In operational and Non-operational terms: Create your Solution Specification
- Reliability goals
- Availability goals
- Serviceability (by Audience with a CX focus)
- Security/Safety Standards
- Performance goals
Compute, Storage, Bandwidth
3rd party Solution Integration functional Scope, Standards
-documentation scope and goals by audience
- training material scope and goals by audience
F. Solutions Architecture: DOCUMENTATION IS KING, SO IS STAKEHOLDER BUY IN
- Document each use case in UML+, Pictures are important, start there ( debating & arguing in text/email is pointless)
- Detail Workflow of the Oracle in the form of Methods and Systems (you might have to write a patent or two to protect Oracle IP)
- get sign off from the key stakeholders your target market Benefactors: The Users of the Services
- CX "Customer Experience" is king these days (don't push the tech, get validation of the value you create)
- Get sign -off from the VCs, Investors,
G. SOFTWARE ARCHITECTURE- Set Expectations of Solution AND team Performance AND Emphasis/Focus Phase by Phase, UP FRONT
- This the time to re-iterate the Vision, Direction, Strategy and Tactics to be employed when building your crypto Oracle
- Emphasize, Up front, the clear separation between make and buy, and what happens to that split, when you over or under perform, measured after each sprint
TK note- I am assuming the scrum master is in the loop, Agile approach is in use and Sprints are short with well defined Scopes and Expected Outcomes
- Let the CTO lead and the Software Development close, take Q & A after each section of the Requirements Review
- Walk through the Expected Outcomes and Test Cases + Pass/Fail Metrics FIRST, Q&A between groups
- Walk the Use Cases Primary, Secondary and Exception in that order, Q&A between groups
- Layout the Languages to be used for each element of the Oracle (servber vs. UI/UX App, etc..)
- Layout the Make Scope and the buy Scope per Use Case Group
- Detail the Buy/Adopt/Sub contract Scope and how to interact with each.
- Layout the toolchains, development, test and dev ops to be used
- Layout the education program, which must be completed before ANY Lines of code "loc" are written/acquired/integrated and committed
- Review the code/test flow (Leapwork) Review/Approve Commit workflow to be used by each group
- Review the Review Process at the end of each Sprint and focus on Quality Metrics (Bug Count, re-submits, etc..)
- On your mark, get set, go
ORACLES will show us the way to greater and faster cryptocurrency adoption...
The brave new world of oracles is in full gear now within the crypto community with many serious development going on. The future of crypto looks bright indeed. :)
Onward and Upward!
TK over and out.