Tokenized Smart Contract Downtime Consequences and design to minimize them

Here is my conversation started on Telegram and is now being continued here on the forum:

David Lypka, [28.10.19 19:58]
So how is Tokenized going to evolve to be relatively decentralized and not likely to have any unplanned downtime? Right now as I understand it, Solidity contracts are duplicated on every node and all are checked to be sure they arrive at the same result given the same input. I would guess that ultimately Tokenized contracts need to be running on evey mining node at least and they should cross check each other.

Brendan Lee, [28.10.19 19:59]
[In reply to David Lypka]
This is not how Bitcoin works

Brendan Lee, [28.10.19 19:59]
Smart contracts run on their own, and the blockchain serves as an audit trail of their actions

Brendan Lee, [28.10.19 19:59]
If they get it wrong, the incorrect result is recorded on-chain and can be remedied

David Lypka, [28.10.19 19:59]
Bitcoin does not have such Solidity type smart contracts yet

Brendan Lee, [28.10.19 19:59]
Nor will it

David Lypka, [28.10.19 20:00]
yes but the Tokenized smart contract must be seen as dependable service.

David Lypka, [28.10.19 20:00]
so how?

David Lypka, [28.10.19 20:00]
Very bad news if a Tokenzied node or the process goes down.

Brendan Lee, [28.10.19 20:01]
Why?

Brendan Lee, [28.10.19 20:01]
It can be re-started

Brendan Lee, [28.10.19 20:01]
nobody loses anything

David Lypka, [28.10.19 20:01]
Time is lost.

Brendan Lee, [28.10.19 20:01]
The full audit trail is on the blockchain

David Lypka, [28.10.19 20:01]
And I would not count a reboot

Brendan Lee, [28.10.19 20:01]
It can be distributed

Brendan Lee, [28.10.19 20:01]
but this is not a mining function

Brendan Lee, [28.10.19 20:01]
it is something particular to the Tokenized smart contract

David Lypka, [28.10.19 20:02]
Well Tokenize will have critical business logic in it for sure.

Brendan Lee, [28.10.19 20:02]
I’m sure

David Lypka, [28.10.19 20:02]
So is it reasonable to assume that the mining nodes will ultimately host it?

Brendan Lee, [28.10.19 20:02]
no

Brendan Lee, [28.10.19 20:03]
It may be hosted in close proximity to mining nodes, but even that isn’t necessary

David Lypka, [28.10.19 20:03]
Well I mean on the mining nodes as a way to save money - just piggy back it on the miner’s network.

David Lypka, [28.10.19 20:04]
Anyway that is good news if you are explaining that Tokenize can just restart and it will recover state from the blockchain.

Brendan Lee, [28.10.19 20:04]
It is a second layer protocol. Every tokenized transaction has the full security of the Bitcoin network to back its authenticity

Curtis Ellis, [28.10.19 20:05]
The host of the smart contract is responsible for the uptime of the smart contract agent. It isn’t related to mining, though large contracts will probably want good access to the network.

The smart contract agent can be distributed, but is not decentralized and can’t be since it requires some physical asset to be held by the contract administrator on the token holders behalf.

This page explains the trust involved with tokens.
https://tokenized.com/docs/intro/philosophy#trust

David Lypka, [28.10.19 20:05]
Seems like there is no harm in including it along side every full-node including in the miner;s network.

David Lypka, [28.10.19 20:06]
or near it.

Brendan Lee, [28.10.19 20:06]
[In reply to Brendan Lee]
And to be clear, things like the Lightning Network and sharded blockchains are not second layers. They are secondary networks. A second layer builds itself inside the base protocol.

Curtis Ellis, [28.10.19 20:06]
and yes, since bitcoin is used as the data layer, everything can be recovered from on chain data, so long as the private keys are not lost

David Lypka, [28.10.19 20:06]
to share same security zone.

Brendan Lee, [28.10.19 20:06]
[In reply to David Lypka]
No

Brendan Lee, [28.10.19 20:06]
This is wrong thinking

Brendan Lee, [28.10.19 20:06]
The security zone is the protection given to the private keys that control the contract

David Lypka, [28.10.19 20:06]
Well how to avoid single point of failure scenario

Brendan Lee, [28.10.19 20:07]
it has nothing to do with miners

Brendan Lee, [28.10.19 20:07]
Properly back up your keys

David Lypka, [28.10.19 20:07]
Miners never had to worry about smart contracts potentially making them look bad until now.

Brendan Lee, [28.10.19 20:07]
Miners DGAF

Brendan Lee, [28.10.19 20:07]
What happens in a tokenized contract is not their business

Brendan Lee, [28.10.19 20:08]
All they do is make records when asked

Brendan Lee, [28.10.19 20:08]
If the contract somehow makes an incorrect record, it’s on the operator of that contract to fix it

David Lypka, [28.10.19 20:08]
Well if so much dependence it put on the new smart contracts then if the smart contracts sneeze, everyone catches cold.

Brendan Lee, [28.10.19 20:08]
Not some DAO fork like you get in ETH

Curtis Ellis, [28.10.19 20:08]
[In reply to David Lypka]
it doesn’t really make sense to run it next to every full node. each smart contract agent handles one contract. each contract only requires one agent.

Brendan Lee, [28.10.19 20:08]
[In reply to Brendan Lee]
That;s the real problem for miners

David Lypka, [28.10.19 20:08]
No but what if the tokenized server hardware has a breakdown?

Brendan Lee, [28.10.19 20:09]
[In reply to David Lypka]
Turn on another one and give it the same keys

Brendan Lee, [28.10.19 20:09]
it will synch the contract state

Curtis Ellis, [28.10.19 20:09]
if a smart contract fails it only effects that contract. All contracts are independent entities

Brendan Lee, [28.10.19 20:09]
and start working

Brendan Lee, [28.10.19 20:09]
When there are millions of contracts, there will be millions of agents

Brendan Lee, [28.10.19 20:09]
all are separate

David Lypka, [28.10.19 20:09]
OK so you are explaining that just current failsafe server farm design is enough

Brendan Lee, [28.10.19 20:09]
Yes

David Lypka, [28.10.19 20:10]
Just use clusters and so on.

Brendan Lee, [28.10.19 20:10]
Depends what you’re tokenizing

Brendan Lee, [28.10.19 20:10]
If it’s your pizza shop loyalty points… maybe not

Brendan Lee, [28.10.19 20:10]
if it’s a nation’s fiat currency, then yeah.

David Lypka, [28.10.19 20:10]
I have to get that straight in my mind as I get more experience.

Brendan Lee, [28.10.19 20:11]
[In reply to David Lypka]
Stop thinking as though everyone has to be universally aware of what everyone else is doing. This is the main flaw in Ethereum. The ledger is your tool to record the status of your contract. That is it’s only part in this.

Brendan Lee, [28.10.19 20:11]
You don’t have to care about anyone else’s contract, or what anyone else is doing on the ledger. Nor do they have to care about you.

Brendan Lee, [28.10.19 20:12]
If your contract crashes, it can be recovered. It’s not a huge deal,

Brendan Lee, [28.10.19 20:12]
The important thing is that when your contract crashes, it has zero impact on anything else

Brendan Lee, [28.10.19 20:13]
And it can be fully recovered thanks to having it’s entire state recorded on the ledger

David Lypka, [28.10.19 20:21]
right, OK I will move to the forum. See you there, thanks for the help so far.

Hi David,

Welcome to the Tokenized forum.

Since the state of the smart contract is entirely on-chain, a smart contract agent that goes offline for whatever reason can rebuild its state from the blockchain and catch up on any missed request actions by responding when it comes back online.

One important element for improving the smart contract’s availability (and security) is the use of blinded threshold signatures in an N of M signing arrangement whereby the private key never exists on any machine aka ‘dealerless’ key generation. N is the minimum number of partial signatures required to create a valid signature and therefore a valid Bitcoin transaction containing the Tokenized Protocol response action. M is the number of machines that have partial shares of the private key. These machines can be anywhere and controlled by anyone.