...by Daniel Szego
quote
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego
Showing posts with label crypgraphy. Show all posts
Showing posts with label crypgraphy. Show all posts

Thursday, December 6, 2018

SLA with cryptoeconomical service guarantee


Service level agreements are important parts of every corporate infrastructure and for companies providing infrastructure or even software as a service products. Service level agreements provide at least a theoretical guarantee that if the service is not provided in a promised way, there can be something done. However to really do something if the SLA is not hold is difficult, starting a legal process might take years and cost a lot of money, finding a new provider and migrate existing services to the infrastructure of the new provider might again take month and can be pretty costly. 

A good solution can be however to introduce cryptoeconomical guarantees as insurance for a service, similarly as the Ethereum initiative Swap, Swear and Swindle does for off-chain computation and services. SLA parameters have to be formalized in an explicit and measurable way, and in case the service is not provided, the consumers of the service should be able technically, in a reliable way prove that the SLA was not hold. The service provider should make an insurance up to a certain amount of cryptocurrency that money is held online in a smart contract. Customers of the possible service providers might choose a provider not just based on services but on the fact how much it is cryptoeconomically secured, with other words how much cryptocurrency is locked as an insurance or security deposit in case there are problems with the service If a customer experiences problems with the SLA, an cryptogaphical proof can be generated for that, this proof can be validated by decentralized validators and in case the customer has right a certain amount of cryptocurrency can be transferred, up to the security deposit of the service provider. The whole process might run fully or  almost automatically, practically in minutes.     

Saturday, October 6, 2018

How fair is the transaction ordering in Hashgraph


Hashgraph algorithm and Hedera Hashgraph is said to have a fair ordering mechanism that means that the order of the transactions is created with the help of a general consensus, so practically no node can influence the order of the transactions. It is an improved version of a blockchain mining protocol where a miner can very strongly influence the order of the transactions. 

The situation is actually not so cool. The point is that the algorithm guarantees a fair ordering of the events and not directly the transactions. As soon as a transaction is put into an event the fair ordering can be guaranteed however previously the ordering can be gamed. A node that receives transactions from the outside world can choose to include, not include or delay a transaction. It can also game with the ordering of the different transactions by delaying one with a couple of event round comparing with another one. So actually a node that receives the transaction is pretty much a dictator of that transaction, similarly as a miner is a dictator of the transactions put into a block. For such a "game" in the ordering of the transactions the original source code not necessarily should be modified. It is possible to hack the transactions on the operation system or on the network level.

Considering a Byzantine fault tolerant model meaning that at most one third of the nodes can be hacked, fair ordering of transactions can be only guaranteed if the transaction from the customer side is sent to 33% + 1 nodes.   

Tuesday, July 31, 2018

The difference role of digital signature in UTXO and account based systems


Although the role of cryptogaphy and digital signature is similar in all blockchain systems they behave a little bit differently depending on if we speak about an UTXO or account based system. In an UTXO based system keys represent practically the unspent outputs that can be associated to a public key and can be spent by signing with the private key. Similarly in an account based system each account has an address which is practically a public key. Private key in this scenario simply means that someone has  the access of doing something with the account. like sending money from it, or initiating another transaction like calling a function of a smart contract from that account. Certainly, account based systems are much more vulnerable for reply attacks, meaning that someone copies a correctly signed transaction on the net and tries to broadcast it again into the network. For this reason, account based systems are usually extended by an incremental nonce for the transaction number. 

Account based systems might provide the possibility as well to extend the existing cryptographic scheme with other roles. Let we imagine that the we use multi signature addresses or an account is associated with several different public keys and signing with a certain private key might mean semantically something different than signing with another key. Like one private key is needed to spend money from the account, but another one to initiate a non-money sending transaction.