Tari Protocol Discussion 46

On Monday, the Tari community discussed potential verification times of multiparty payment channels.

Join us for our next discussion on Freenode in #tari-dev.

Discussion times proposed by the Tari community:

Mondays: 6pm CAT (12pm EST)

Thursdays: 11am CAT (5am EST)

To keep up with the latest Tari developments, you can follow the project on Twitter.

Transcript of Monday discussion

18:03 <Hansie> Hi there, time for our Monday dev chat.
18:04 <Hansie> We have explored bounding cases for checkpoint transactions w.r.t. block size. There are also validation time and data transmission size limitations.
18:12 <Hansie> I have refined the numbers a bit, and have a low and high throughput scenario:
18:13 <Hansie> Low
18:13 <Hansie> Transactions/CP               1 440 000
18:13 <Hansie> Transactions/s                    16.00
18:13 <Hansie> Gearing                            1.10
18:13 <Hansie> UTXOs per CP                    432 000
18:13 <Hansie> Kernel data to hash (MB)/CP      146.94
18:13 <Hansie> UTXO data to hash (MB)/CP        293.75
18:13 <Hansie> Data to hash (MB)/CP             440.69
18:13 <Hansie> Data to hash (MB)/min              0.31
18:13 <Hansie> Bulletproof verify (h)            0.054
18:13 <Hansie> Signature verify (h)              0.012
18:13 <Hansie> Hash verify (h)                 0.00013
18:13 <Hansie> Total validation time (h)         0.066
18:13 <Hansie> Validation time/block (s)         0.165
18:13 <Hansie> High
18:13 <Hansie> Transactions/CP             144 000 000
18:13 <Hansie> Gearing                          117.40
18:13 <Hansie> Transactions/s                 1 666.00
18:13 <Hansie> UTXOs per CP                 43 200 000
18:13 <Hansie> UTXO data to hash (MB)/CP     29 374.69
18:13 <Hansie> Kernel data to hash (MB)/CP   14 694.21
18:13 <Hansie> Data to hash (MB)/CP          44 068.91
18:15 <Hansie> Validation times estimated based on single core operation of an Intel Core i7-6820HQ clocked at 2 GHz.
18:16 <Hansie> For 14 400 000 users in the DAN
18:16 <Blackwolfsa> is an i7 not a bit too highpowered for this test?
18:18 <Hansie> Maybe, maybe not, just a peg in the sand.
18:18 <Hansie> Refunds for both scenarios looks as follows:
18:18 <Hansie> Transactions/CP             14 400 000.00
18:18 <Hansie> UTXOs per CP                14 400 000.00
18:18 <Hansie> Kernel data to hash (MB)/CP      1 469.42
18:18 <Hansie> UTXO data to hash (MB)/CP        9 791.56
18:18 <Hansie> Data to hash (MB)/CP            11 260.99
18:18 <Hansie> Bulletproof verify (h)               1.80
18:18 <Hansie> Data to hash (MB)/min                7.82
18:18 <Hansie> Signature verify (h)                 0.12
18:18 <Hansie> Hash verify (h)                    0.0029
18:18 <Hansie> Total validation time (h)           1.923
18:18 <Hansie> Validation time/block (s)           4.807
18:19 <Hansie> Blackwolfsa: This is just to get a feel for the size of the problem.
18:26 <Hansie> The premise of this scheme is for users to pay funds into a single committee controlled UTXO (checkpoint UTXO), and to get an equal amount of funds available in the payment channel. This peg-out to be atomic, with a commitment to the payment channel state. The committee will ever only have one checkpoint UTXO on the base layer, always spending the
18:26 <Hansie> previous checkpoint UTXO.
18:26 <Hansie> Base nodes are then required to validate the supporting data set for the checkpoint.
18:30 <Hansie> Checkpoints involve committing to the set of information that fully describes the state of all payment channel transactions and UTXOs at a certain point in time, and to immutably add that result to the Mimblewimble blockchain.