Hi Troops
Would appreciate further feedback/views on the subject matter of concurrency and what solutions that are currently : work in progress and or, already resolved ?
Do we anticipate any impact with Goguen whilst awaiting a fix for this
Cheers
I think the issue is bigger than just concurrency. The effective limit on number of inputs and outputs in a transaction might make distributed state essential for a complex smart contract that intends to hold a lot of information.
There is a body of computer science literature on distributed computing, petri nets, concurrent discrete-event simulation, and state machines that is relevant. I presume that the solutions will draw on that. My guess is that use-case specific solutions will emerge in time for Goguen, but that a fully general solution could take a while.
For a āsmart contractā to be deterministic would it not require a finite state machine?
It seems the problem here, as with many blockchains trying to attain higher throughput, is settling the resolution of transactions within the single congruent ledger impacted by multiple dependencies. Of course a much simpler solution is do not compete with VISA ā¦
Do you buy a house with a credit card today?
Do you buy a sandwich with a smart contract today?
Which of these needs to be changed?
I keep circling back to trying to identify what problems blockchains and cryptocurrency solve. The more I think about it the less I think throughput, concurrency, and similar complaints matter. Supporting day traders is irrelevant. Of course whenever I try to think outside the box I typically just find another box ā¦
Thanks for the replies aboveš
My apologies for the delay in responding, been having a few challenges with health issues with my father.
Kind regards
A brilliant follow-up article that outlines the issue more generally & historically, along with some promising advancements made in the last 2 monthsā¦
ā¦ and another leap forward 
After reading the eUTXO paper online. Iād like to offer some feedback that might be able to help with the concurrency issue. It seems like there is an easy fix to this. In looking at the fields in the eUTXO model the following fields exist in the transaction:
Quantity an amount of currency
Tick a tick
Address an āaddressā in the blockchain
Data a type of structured data
DataHash the hash of a value of type Data
TxId the identifier of a transaction
txId : Tx ā TxId a function computing the identifier of a transaction
Script the (opaque) type of scripts
scriptAddr : Script ā Address the address of a script
dataHash : Data ā DataHash the hash of an object of typeData
J K : Script ā Data Ć Data Ć Data ā B applying a script to its arguments
Defined types
Output = (value : Quantity,
addr : Address,
datumHash : DataHash)
OutputRef = (id : TxId, index : N)
Input = (outputRef : OutputRef,
validator : Script,
datum : Data,
redeemer : Data)
Tx = (inputs : Set[Input],
outputs : List[Output],
validityInterval : Interval[Tick])
Ledger =List[Tx]
Judging from what Iām seeing here the transaction model lacks a nonce. A number that can be used only once during the current tick. This ultimately results in a concurrency issue as someone submitting numerous transactions in a very short period of time would only be limited to one transaction per time slice. This is a very easy fix. Adding an additional field called a nonce to the transaction would easily resolve the issue as the nonce would then allow someone to add multiple unique transactions in a single tick due to the fact that a nonce is a unique number that is used to differentiate transactions. It also allows you to differentiate multiple identical transactions being submitted at once.
Now Iām not a Cardano developer. Iām just trying to provide some helpful feedbackā¦ Please let me know if this solution is helpful or if you already have a solution. But this should quickly resolve the concurrency issue with a minimal amount of effort on your part
If you have any questions please let me know. I also have some ideas on how to eliminate the 50% attack if youāre interested too.
Iāve looked at the code in Cardano. And from as far as I can gather my original assessment is correct. no nonce.
@Philip_Neves I donāt see how merely introducing a ānonceā helps settling the ledger while preventing double-spend and other problems for all transactions in a given slot.
If multiple transactions are being initiated from multiple wallets at the same moment (perhaps many of which for the same wallet or even the same addresses) than resolving that concurrency doesnāt get any easier due to an additional id ā¦ transactions already have unique ids.
If you mean introducing a nonce that locks a sequential ordering of transaction processing for every slot than you destroy scalability and performance and solve the concurrency issue by simply not having any. In theory with infinite concurrency support you could submit unlimited transactions. They may not all succeed or fold into the blockchain depending on resolution of settled state and errors that occur but that should always be handled as well.
Could you elaborate with an algorithm or pseudo code example of how this would resolve the following overly simplified example:
Assumptions:
Ignore minADA, Tx processing fees, etc
Wallet A has 10 ADA
Wallet B has 10 ADA
Wallet C has 10 ADA
Transactions:
A sends 5 ADA to B
B sends 10 ADA to C
C sends 15 ADA to A
A sends 10 ADA to B
Now of course I wrote this as a āsunny dayā scenario and also in a sequential order so you can obviously see how each wallet would be able to fund the transactions successfully. However the issue is both A & C are technically sending more than their initial known balance. A is doing so across 2 transactions while C is doing so in 1 transaction. However a truly concurrent transaction model should resolve the settled balances as below.
Settled Balances:
A has 10 ADA
B has 15 ADA
C has 5 ADA
The problem with concurrency is they could be in any order and the model and protocol itself needs to determine the proper resolution. This includes rejecting some but not all transactions based on the intermediate state during transition to the next state such that every slot, block, epoch, etc is always deterministic and correct at all times on the ledger.
The issue I see with this is what if you have two transactions that come in in the same block that are completely identical. In protocols such as TCP/IP to ensure that two identical packets are differentiated they introduce a nonce.
The issue Iām trying to address here is that what if
A wants to send 10 ADA to B over and over again in a very short period of time?
A has 10 ada
A sends 1 ada to B
A sends 1 ADA to B
A sends 1 ADA to B
How do you differentiate that from someone just accidentally resubmitting the same transaction over and over again. The nonce is kinda necessary for this because all things being equal you need to differentiate between accidental resubmissions and legitimate identical submissions of equivalent transactions. I know this is an edge case but should there not be something to deal with such situations?
Oh sorry, I thought you meant the broader issue with concurrency.
For something as simple as a flood gate the minAda portion of the Cardano protocol already makes that extremely cost prohibitive to abuse. Spamming millions of transactions would literally require millions of ADA to be locked up in the process.
As far as wallets and users submitting multiple legitimate identical transactions that is handled by unique transaction ids, the negotiation phase, signing, confirmation, etc.
As far as mistaken āduplicationā of transactions due to a bug I wasnāt aware that was an issue that needed resolution?
This I believe would only be an issue if its done in the same time slice. I think. I could be wrong too right.
Every slot is exactly 1 second so I suppose itās theoretically possible ā¦ thatās one hell of a super user who could enter addresses, tx details, sign and submit multiple times in the same second!
Application use cases from smart contracts may still require some off-chain negotiation even if itās with ultra fast paced platform. Worse case scenario I can think of would be a āblinkā style auction house with a user resolution much faster than milliseconds. You would likely need to design a ābid queueā into your app. Then once the auction and frenzied bidding had ended you would submit the winner to the blockchain and give them X amount of time to confirm before cancelling and offering the runner-up a shot at claiming the prize. Kind of like eBay does I guess. Instead of PayPal or ACH you just submit the finalized transaction to the blockchain instead.
Iām not building anything that demanding. I was just trying to provide some input to help resolve this Concurrency controversy If my suggestion was or is valid it would be a very simple fix. However, Charles has addressed some of it already with his video. So hopefully that calms people down a bit.
The concurrency problem may have been kind of overblown honestly.