Thoughts and ideas following this story are welcome.

Hi Clara, interesting read. The last part confuses me a little: Does this mean that until the 'one property rule to rule them all' has been found, the coordinator can not be shut off permanently?

Have you looked at the PARSEC consensus protocol? https://medium.com/safenetwork/parsec-a-paradigm-shift-for-asynchronous-and-permissionless-consensus-e312d721f9d8 

I am by no means an expert so maybe I am comparing apples with oranges here, but it seems like it could be beneficial to IOTA as well.

+x

 

pevw - 2 Oct 2018

Hi Clara, interesting read. The last part confuses me a little: Does this mean that until the 'one property rule to rule them all' has been found, the coordinator can not be shut off permanently?

Have you looked at the PARSEC consensus protocol? https://medium.com/safenetwork/parsec-a-paradigm-shift-for-asynchronous-and-permissionless-consensus-e312d721f9d8 

I am by no means an expert so maybe I am comparing apples with oranges here, but it seems like it could be beneficial to IOTA as well.

This is not standing in the way of shutting of the coordinator.
We have safe properties, but there are other things to take into account and we are considering them.

Hi Clara,

Very interesting reading. I have some thoughts on this subject, but I'm not sure where to start with. I believe we need some consensus what the discussion should be based on. So let me first ask a question: Did you ever made an entry in a conventional ledger? This may sound very personal, but it is very important to decide on the level of discussion. Thanks in advance.

Hello Clara,

thanks for this article - this was a very interesting read!
May I lead my post with asking if you are looking for any more researchers in this area?

I myself was asking questions about the validity problem in the Tangle before and actually planned on basing my diploma thesis on this topic. I wanted to focus more on the transaction ordering of smart contacts, because i found the Qubic roadmap a bit lacking in this regard (there is a comprehensive section on the processing phase of a single epoch, but not on how one would base a transaction on top of another) - so this seemed like a wonderful opportunity to start some research by defining basic requirements a smart contract must fulfill; and how such properties could look like in a DAG. 

But your work seems even more fundamental than that, so I'd like to ask how advanced your work already is, and if you would be interested in some kind of collaboration? I'm a master's degree student of computer sciene at the Technical University of Vienna and me and my professor would be happy to work together with the IOTA foundation on solving these fascinating problems - and improving IOTA on the way. 

Best,
Lukas

Well, I have to start from scratch then.

“Ledger” is the main book where all transactions of an entity (usually a fiscal account) are recorded. Due to physical constraints of a book, transactions are in “total-order”. They are entered row after row. Neither deletions nor updates are allowed. Corrections are realized by a counter transaction which zeroes the effect of a former one. Every page in the book has a page number, a starting- and an ending-balance. Minimum information a transaction carries are: Date of issue, Sending Account-Id, Receiving Account-Id, and Amount due to transfer. If one is not happy with this definition s/he is not talking about “ledger”.

Because ledgers are in total-order by definition, “ordered list” is the natural choice of their modelling. Very often subaccounts of the entity are used to achieve detailed recording. Heavily use of subaccounts suggests a two-dimensional model for a better organization. In this case a model based on “directed acyclic graph” is inevitable. Please note the two principles, though:

1. Transactions must be kept in total-order by subaccount
2. Ledger must be kept in partial-order

So far so good. In Clara’s post we read:

However, since the Tangle is a Directed Acyclic Graph (DAG), the question of time-ordering becomes non-trivial. The DAG structure makes it hard, or sometimes impossible, to resolve whether a payer has received coins before spending them.

This statement is misleading. In reality Tangle’s choice of connecting transactions arbitrarily (in a disordered manner as a result of "Random Walk"), makes it impossible to time-order transactions, not the DAG structure. A DAG structure does not prescribe "why" two nodes are connected, or "what" the connection means. It merely says, if two nodes (subject and object) are connected by an arc (predicate), they must be interpreted following the rule of transitivity. So, for Tangle there is no escape to live with the consequences of its own choice, and DAG structure cannot be blamed for it. The bottom line is: if “confirms”, which supposedly is the predicate connecting two transactions in Tangle, does not include validation, there is no way one can examine the validity of a transaction. Not to forget, not time-order is decisive for the validity of a transaction, but its relative-order of realization with respect to other transactions within the infrastructure.
By the way, my article "Directed Acyclic Graphs, Data-Flow, and Distributed Ledgers" may be an interesting introduction how to achieve a two-dimensional model of a ledger, while obeying the principles mentioned earlier.

+x

 

Enis Olgac - 2 Oct 2018

Hi Clara,

Very interesting reading. I have some thoughts on this subject, but I'm not sure where to start with. I believe we need some consensus what the discussion should be based on. So let me first ask a question: Did you ever made an entry in a conventional ledger? This may sound very personal, but it is very important to decide on the level of discussion. Thanks in advance.

I have, but I would suggest to keep it basic so others can join.

+x

 

luhe - 2 Oct 2018

Hello Clara,

thanks for this article - this was a very interesting read!
May I lead my post with asking if you are looking for any more researchers in this area?

I myself was asking questions about the validity problem in the Tangle before and actually planned on basing my diploma thesis on this topic. I wanted to focus more on the transaction ordering of smart contacts, because i found the Qubic roadmap a bit lacking in this regard (there is a comprehensive section on the processing phase of a single epoch, but not on how one would base a transaction on top of another) - so this seemed like a wonderful opportunity to start some research by defining basic requirements a smart contract must fulfill; and how such properties could look like in a DAG. 

But your work seems even more fundamental than that, so I'd like to ask how advanced your work already is, and if you would be interested in some kind of collaboration? I'm a master's degree student of computer sciene at the Technical University of Vienna and me and my professor would be happy to work together with the IOTA foundation on solving these fascinating problems - and improving IOTA on the way. 

Best,
Lukas

Hi Lukas,

We love cooperations with external researchers and this sounds like a good opportunity.
I'll message you with some contact details.

Best,
Clara.

+x

 

Enis Olgac - 4 Oct 2018

Well, I have to start from scratch then.

“Ledger” is the main book where all transactions of an entity (usually a fiscal account) are recorded. Due to physical constraints of a book, transactions are in “total-order”. They are entered row after row. Neither deletions nor updates are allowed. Corrections are realized by a counter transaction which zeroes the effect of a former one. Every page in the book has a page number, a starting- and an ending-balance. Minimum information a transaction carries are: Date of issue, Sending Account-Id, Receiving Account-Id, and Amount due to transfer. If one is not happy with this definition s/he is not talking about “ledger”.

Because ledgers are in total-order by definition, “ordered list” is the natural choice of their modelling. Very often subaccounts of the entity are used to achieve detailed recording. Heavily use of subaccounts suggests a two-dimensional model for a better organization. In this case a model based on “directed acyclic graph” is inevitable. Please note the two principles, though:

1. Transactions must be kept in total-order by subaccount
2. Ledger must be kept in partial-order

So far so good. In Clara’s post we read:

However, since the Tangle is a Directed Acyclic Graph (DAG), the question of time-ordering becomes non-trivial. The DAG structure makes it hard, or sometimes impossible, to resolve whether a payer has received coins before spending them.

This statement is misleading. In reality Tangle’s choice of connecting transactions arbitrarily (in a disordered manner as a result of "Random Walk"), makes it impossible to time-order transactions, not the DAG structure. A DAG structure does not prescribe "why" two nodes are connected, or "what" the connection means. It merely says, if two nodes (subject and object) are connected by an arc (predicate), they must be interpreted following the rule of transitivity. So, for Tangle there is no escape to live with the consequences of its own choice, and DAG structure cannot be blamed for it. The bottom line is: if “confirms”, which supposedly is the predicate connecting two transactions in Tangle, does not include validation, there is no way one can examine the validity of a transaction. Not to forget, not time-order is decisive for the validity of a transaction, but its relative-order of realization with respect to other transactions within the infrastructure.
By the way, my article "Directed Acyclic Graphs, Data-Flow, and Distributed Ledgers" may be an interesting introduction how to achieve a two-dimensional model of a ledger, while obeying the principles mentioned earlier.

Hi, the link to my article was broken. Thanks for letting me know, Clara. Here is the correct link:

Directed Acyclic Graphs, Data-Flow, And Distributed Ledgers

Thanks again.