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 AMA Mondays on Komodo’s subreddit and the Five Bullet Fridays weekly newsletter, Tech Tuesday Updates will be another weekly piece of content to look forward to.
Without further ado, here are the past week’s tech highlights!
Smart Contract Oracles
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 a smart contract for oracle services 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 smart contract 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 UTXO Smart Contract) 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 + Smart Contracts
ac_cc 2–100 = clustered federation of chains validating each other + Smart Contracts
ac_cc 1 = Smart Contracts
ac_cc 0 = No Smart Contracts
For more information on configurations for your Komodo-based blockchain, please have a look at the Crypto-Conditions (ac_cc) parameter definition and the other customizable blockchain options for chains launched on Komodo Platform.
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 smart contracts.
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.
Ethereum Notarizations
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 get more updates from Komodo, sign up for our weekly Five Bullet Fridays newsletter and join our active community on Discord.
Join us as we continue to develop and lead the blockchain industry into the future.
