Things move fast at Komodo Platform. That’s why the Komodo team has decided to release a weekly briefing to cover all of the progress the Dev Team is making.
This series of posts is called the Tech Tuesday Updates. Along with the weekly newsletter, Tech Tuesday Updates will be another weekly piece of content to look forward to.
In case you've missed a previous edition and want to catch up, you can find all the previous Tech Tuesday updates here.
Without further ado, here are the past week’s tech highlights!
Oracles Custom Consensus Module
Komodo’s Lead Developer, jl777, recently developed a way to create oracles on Komodo Platform. This allows you to turn your off-chain data into on-chain data through “sanctioned” data providers. The sanctioning is done by convention through using accepted pubkeys. However, this does not require a smart contract!
Where the Oracles Custom Consensus module becomes useful is to provide payments for oracle providers. Further, this contract mechanism isn’t limited to payments— without using too much imagination, it could be used for censoring or dispute resolution as well.
Oracle custom consensus module outputs begin with a simple “name/description” transaction. From this transaction, “data provider” and “data users” are then created— both are derived from the name/description transaction (like any Custom Consensus modulef) and result in transactions which are used throughout the contract’s life (cycle).
Sybil protection? Yes. In order to prevent abuse, the data providers query has a cost.
Performance of oracle data? There are additional transactions created for marking the start of oracle services (per service) and a “marker” transaction (also per service) which is somewhat dynamic. Being dynamic it has been named a “baton” transaction. This baton transaction is simply a reversed linked-list of data going from the most recent data linked back to the starting point of the blockchain enforced oracle data.
Create A Blockchain With Different Smart Contract Interoperability Options
Komodo’s continued focus on independent blockchain created with Komodo’s technology highlights these key features:
- Each chain is independent
- Each of these independent chains runs CC contracts independently of each other.
The only exception would be cross-chain contracts that use a transaction from other chains as input to their local contracts.
For fungibility between chains, the -ac_cc parameter at chain launch needs to be set to at least 101. If a chain is launched as a cluster of chains, the validation of transactions between chains needs this -ac_cc parameter set between 2-100.
Here are the parameters:
ac_cc > 100 = MoMoM + Custom Consensus framework
ac_cc 2-100 = cluster of chains validating each other + Custom Consensus framework
ac_cc 1 = Custom Consensus framework
ac_cc 0 = No Custom Consensus framework
For more information on configurations for your Komodo-based blockchain, please have a look at the Custom Consensus (ac_cc) parameter definition and the other customizable blockchain options for chains launched with Komodo's technology.
Testing Cross Chain Fungibility
As usual, the #STAKED channel on Komodo’s Discord server make their own testing rules from week to week. They have been collaborating with Komodo team member libscott for testing cross chain fungibility.
Other details from last week are included in the STAKED weekly report. The STAKED community found a smart contract (still in heavy development) activation bug which will one day be a useful parameter for existing assetchains to activate the Custom Consensus framework.
For this week, they’ve been busy getting a testnet notary network up for cross-chain fungibility testing. The early goals have been one-way fungibility. These seem to have passed without any problems. No lost coins, no coins created out of thin air.
There is a team of community members helping libscott test the notarization process with Ethereum and ERC20 tokens. The first notarizations happened on Friday, August 31.
For public testing, the ETH notarization to KMD happens by syncing Komodo and importing your private key. In production, this will be a notary node operator’s function. Once synced, installing the hath software written by libscott and running the Ethereum client geth is required.
Finally the BTC pubkey of the corresponding Komodo address is included in a mandate contract. Those keys in the mandate contract are the ones that can do the notarization to KMD.
No other process has been tested as yet but this is an ongoing engineering project within the Komodo Ecosystem.
Why Agama Wallet May Set Off Anti-Virus Alarms
When packaging up Komodo dApps, the release engineering specialists run through all the AV checks. The AV manufacturers like AVG, Avast, ZoneAlarm & Kaspersky set off “not a virus” warnings about cryptocurrency mining with some packages. This is because some of the crypto-libs (cryptography libraries) are used in other legitimate projects and, unfortunately, some illegitimate scams.
These crypto-libs are safe. They are as safe as dollar bills in that it’s not the dollar bills that cause damage to the world (with bombs and illicit substances). The crypto-libs are sometimes used by nefarious third parties— just like the aforementioned bombs and illicit substances..
Agama comes with an option to run in Lite/SPV mode for easy everyday use, it also has full/native mode which includes the Komodo daemon (server software). The daemon is used for mining on the network (by Notary Nodes) for creating consensus. This is the component that triggers the AV warnings. It is completely safe to use in the Agama wallet. Agama wallet is not used for anything but the user’s instructions and benefits.
To be among the first to receive future updates, sign up for Komodo’s weekly newsletter. Every Friday, we’ll send you the 5 most important developments from the previous week. You can also join the Komodo community on Discord to get real-time updates and chat with Komodo team members.
Join us as we continue to develop and lead the blockchain industry into the future.