From fdb3b0d15f9bc3d777851e5444dc3ef31414c2a0 Mon Sep 17 00:00:00 2001 From: builder Date: Tue, 3 Dec 2024 16:36:17 +1000 Subject: [PATCH 01/15] Terminada-CPS-block-delay-centralisation --- CPS-XXXX/README.md | 82 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 CPS-XXXX/README.md diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md new file mode 100644 index 000000000..34cef76a1 --- /dev/null +++ b/CPS-XXXX/README.md @@ -0,0 +1,82 @@ +--- +CPS: ? +Title: Ouroboros not accounting for typical global network delays causes centralisation +Status: Open +Category: ? +Authors: Terminada +Proposed Solutions: [] +Discussions: https://github.com/cardano-foundation/CIPs/pull/? +Created: 2024-10-22 +License: CC-BY-4.0 +--- + +# CPS-XXXX: Ouroboros not accounting for typical global network delays causes centralisation + +## Abstract +An underlying assumption in the design of Cardano's Ouroboros protocol is that the probability of a stake pool being permitted to update the ledger is proportional to the relative stake of that pool. However, the current implementation does not properly realise this design goal. + +Minor network delays endured by some participants cause them to face a greater number of fork battles. The result is that more geographically decentralised participants do not obtain participation that is proportional to their relative stake. This is both a fairness and security issue. + +## Problem +The [Ouroboros Praos paper]() states that it is the "*probability of being permitted to issue a block*" that "is proportional to the relative stake a player has in the system". However, it is clear from the security analysis section that it is the _probability of contributing to the ledger_ that is supposed to be proportional to the relative stake of the participant. This is an important distinction because it matters little if a player has stake weighted permission to make blocks if the protocol later disproportionately drops that players blocks despite their honest performance. + +With the current Ouroboros implementation where slots have 1 second duration, it is not uncommon to have consecutive slot leaders that are only 1 second apart. Remote participants may be unable to receive the previous block within 1 second and so these block producers will make blocks that result in forks. Ouroboros settles such forks by preferring the fork whose terminal block has the lowest VRF value. This seems like a fair method because it is deterministic, neither player can alter the outcome, and each player has an equal chance of winning. However, the problem is that the more geographically decentralised players will face a disproportionately greater number of "fork battles". This in turn means that they will get more of their blocks dropped. The net result is that more geographically decentralised participants do not receive stake weighted _probability of contributing to the ledger_. This is not only unfair, but also represents a deviation from the Ouroboros security analysis assumptions. + +This might seem like a minor problem, but the effect is significant. If the majority of the network reside in USA - Europe with close connectivity and less than 1 second propagation delays, then those participant pools will see 5% of their blocks suffering "fork battles" which will only occur when another pool is awarded the exact same slot (ie: a "slot battle"). They will lose half of these battles on average causing 2.5% of their blocks to get dropped, or "orphaned". + +However, for a pool that happens to reside on the other side of the world where network delays might be just over 1 second, this pool will suffer "fork battles" not only with pools awarded the same slot, but also the slot before, and the slot after. In other words, this geographically decentralised pool will suffer 3 times the number of slot battles, amounting to 15% of its blocks, and resulting in 7.5% of its blocks getting dropped. The numbers are even worse for a pool suffering 2 second network delays because it will suffer 5 times the number of "fork battles" and see 12.5% of its blocks "orphaned". This not only results in an unfair reduction in rewards, but also the same magnitude reduction in contribution to the ledger. + +Even the high quality infrastructure of a first world country like Australia is not enough to reliably overcome this problem due to its geographical location. But is it reasonable to expect all block producers across the world to receive blocks in under one second whenever the internet becomes congested, or if block size is increased following parameter changes? Unfortunately, the penalty for a block producer that cannot sustain this remarkable feat of less than 1 second block receipt and propagation, is 3 times as many "fork battles" resulting in 7.5% "orphaned" blocks rather than 2.5%. + +Considering that most stake pools are competing over 1% or less in fees, these are big numbers. The obvious solution for the remote pool is to move its block producer to a server housed in USA or Europe. This illustrates not only the centralisation problem created, but also the reduction in security that flows from running a block producer on someone elses computing hardware. + +## Goals +Cardano should live up to its [11 blockchain tenets]() proposed by Prof Aggelos Kiayias, in particular T8 and T11 which speak to treating participants fairly without asymmetries. + +## Possible Solutions +1. Modify how stake pools calculate their slot leadership by including ```mod 2``` or ```mod 3``` in the formula so that only every second or third slot is a possible leader slot. Then adjust other parameters so that the Cardano network still produces a block every 20 seconds on average. + + A consequence of this change would be an increased number of true "slot battles", where two pools are awarded the exact same slot. However such battles are fairly settled by preferring the lowest block VRF and cannot be gamed by a malicious actor. + +2. Increase the slot duration to 2 or 3 seconds. However this could have consequences for dapps that have assumed a slot will always be 1 second. + +## Considerations +1. What is a reasonable expectation for block producers housed across the world to achieve in terms of network delays? Is 2 seconds of network delay enough time before block producers get penalised, or would 3 seconds be more appropriate? + +2. What internet infrastructure and geographical location does Cardano consider as a minimum requirement in order to fairly contribute to its ledger? + +3. It would seem to be an advantage to encourage fair participation from people residing in countries on the other side of the globe because this might provide resilience against political or other attacks localised to Europe or USA. + +4. Would there be any impact on the Ouroboros 5 second delta parameter? + +5. Would it be appropriate to make the window in which the block VRF tie breaker rule is applied also the same 2 or 3 seconds so that only blocks with the exact same slot number are deterministicly settled using the block VRF, otherwise the node would prefer its current block? Such a change would remove the ability of malicious actors to deliberately cause a fork with the previous block when they know their block VRF is lower. + +6. What effect could any change have on the solution to [issue #2913: Consensus should favor expected slot height to ward off delay attack]()? + +## Arguments against correcting this unfairness +1. It doesn't matter where the block producer is warehoused because block production is like a virtual service that can be run from anywhere. What really matters is ownership of the pledge and stake, not ownership of the computing hardware. If you live on the other side of the world, just rent a virtual server in Frankfurt or Los Angeles for your block producer. + +- Centralising Cardano infrastructure to data centres potentially hands control over the software, as well as selective control over block propagation between nodes, to BigTech data centre owners. + +2. The internet infrastructure is centred in USA and USA is more politically stable and less likely to have its internet infrastructure compromised through acts of war. If conflict between USA, China, and Russia ensues then the undersea cables to Japan, Australia and New Zealand could get damaged. Therefore it makes sense that Cardano block production should be slightly advantaged in USA and slightly disadvantaged in Japan, Australia and New Zealand. + +- Japan, Australia and New Zealand are very politically stable and it might actually be a good idea to _fairly_ incentivise participation from people living in those areas. If internet connectivity was to be affected by cyber warfare, the targets of such attacks may not be predictable today. + +- The bottom line is that if I have 0.001% of stake in the system then I should get 0.001% of access to the system. Likewise with scaling that up, if good actors possess 51% of the stake then they should have 51% of the control, as this is a fundamental assumption protecting Cardano. I hope that the Cardano community won't step away from this fundamental mathematics based approach in favour of some sort of subjective human inference about where they think block producers should be warehoused for political or other reasons. + +3. Internet transmission is improving so in the future 1 second might be sufficient for block propagation across the entire globe. + +- This unfairness problem doesn't seem hard to fix. If / when internet speeds improve then it should be straightforward to recalibrate the software again. + +4. Won't halving or one-third'ing the number of potential leader slots reduce the number of blocks and therefore reduce the throughput? + +- Possible solution 1 also involves adjusting other parameters so that the target rate of block production remains unchanged. Actually, it seems likely that the realised throughput would slightly increase. The reason for this is that [possible solution 1](#Possible-Solutions) would eliminate forks caused by 1 second propagation delays which currently are wasted throughput. + +5. If my pool is located close to the majority then I am benefitting from this unfairness so why should I vote for this to be fixed? + +- See section: [Goals](#Goals). Hopefully most people in Cardano want to build a fair system for everyone no matter where they live. + +## Copyright +This CIP is licensed under [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/legalcode). + +**** From 64dec3e48795c32f71e962f82a0b3a06a09d723f Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 3 Dec 2024 17:50:06 +0530 Subject: [PATCH 02/15] convert authors to mandated list format --- CPS-XXXX/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 34cef76a1..fb0116044 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -3,7 +3,8 @@ CPS: ? Title: Ouroboros not accounting for typical global network delays causes centralisation Status: Open Category: ? -Authors: Terminada +Authors: + - Terminada Proposed Solutions: [] Discussions: https://github.com/cardano-foundation/CIPs/pull/? Created: 2024-10-22 From cb416da42c4880d199c73e2bf88acd2227b5ae01 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 3 Dec 2024 17:50:39 +0530 Subject: [PATCH 03/15] put Discussions in list format, set current discussion --- CPS-XXXX/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index fb0116044..9ccc82123 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -6,7 +6,8 @@ Category: ? Authors: - Terminada Proposed Solutions: [] -Discussions: https://github.com/cardano-foundation/CIPs/pull/? +Discussions: + - https://github.com/cardano-foundation/CIPs/pull/943 Created: 2024-10-22 License: CC-BY-4.0 --- From e7520b910912c652bd2dd68b5e7932db25fa53eb Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 3 Dec 2024 17:51:05 +0530 Subject: [PATCH 04/15] remove superfluous H1 document title --- CPS-XXXX/README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 9ccc82123..95909292b 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -12,8 +12,6 @@ Created: 2024-10-22 License: CC-BY-4.0 --- -# CPS-XXXX: Ouroboros not accounting for typical global network delays causes centralisation - ## Abstract An underlying assumption in the design of Cardano's Ouroboros protocol is that the probability of a stake pool being permitted to update the ledger is proportional to the relative stake of that pool. However, the current implementation does not properly realise this design goal. From f9cf028fb06e955619ae9d017ade4c17413cc377 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 3 Dec 2024 17:52:55 +0530 Subject: [PATCH 05/15] fix indentation level of responses in FAQ section --- CPS-XXXX/README.md | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 95909292b..018ba2f75 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -53,28 +53,22 @@ Cardano should live up to its [11 blockchain tenets]()? -## Arguments against correcting this unfairness +### Arguments against correcting this unfairness 1. It doesn't matter where the block producer is warehoused because block production is like a virtual service that can be run from anywhere. What really matters is ownership of the pledge and stake, not ownership of the computing hardware. If you live on the other side of the world, just rent a virtual server in Frankfurt or Los Angeles for your block producer. - -- Centralising Cardano infrastructure to data centres potentially hands control over the software, as well as selective control over block propagation between nodes, to BigTech data centre owners. + - Centralising Cardano infrastructure to data centres potentially hands control over the software, as well as selective control over block propagation between nodes, to BigTech data centre owners. 2. The internet infrastructure is centred in USA and USA is more politically stable and less likely to have its internet infrastructure compromised through acts of war. If conflict between USA, China, and Russia ensues then the undersea cables to Japan, Australia and New Zealand could get damaged. Therefore it makes sense that Cardano block production should be slightly advantaged in USA and slightly disadvantaged in Japan, Australia and New Zealand. - -- Japan, Australia and New Zealand are very politically stable and it might actually be a good idea to _fairly_ incentivise participation from people living in those areas. If internet connectivity was to be affected by cyber warfare, the targets of such attacks may not be predictable today. - -- The bottom line is that if I have 0.001% of stake in the system then I should get 0.001% of access to the system. Likewise with scaling that up, if good actors possess 51% of the stake then they should have 51% of the control, as this is a fundamental assumption protecting Cardano. I hope that the Cardano community won't step away from this fundamental mathematics based approach in favour of some sort of subjective human inference about where they think block producers should be warehoused for political or other reasons. + - Japan, Australia and New Zealand are very politically stable and it might actually be a good idea to _fairly_ incentivise participation from people living in those areas. If internet connectivity was to be affected by cyber warfare, the targets of such attacks may not be predictable today. + - The bottom line is that if I have 0.001% of stake in the system then I should get 0.001% of access to the system. Likewise with scaling that up, if good actors possess 51% of the stake then they should have 51% of the control, as this is a fundamental assumption protecting Cardano. I hope that the Cardano community won't step away from this fundamental mathematics based approach in favour of some sort of subjective human inference about where they think block producers should be warehoused for political or other reasons. 3. Internet transmission is improving so in the future 1 second might be sufficient for block propagation across the entire globe. - -- This unfairness problem doesn't seem hard to fix. If / when internet speeds improve then it should be straightforward to recalibrate the software again. + - This unfairness problem doesn't seem hard to fix. If / when internet speeds improve then it should be straightforward to recalibrate the software again. 4. Won't halving or one-third'ing the number of potential leader slots reduce the number of blocks and therefore reduce the throughput? - -- Possible solution 1 also involves adjusting other parameters so that the target rate of block production remains unchanged. Actually, it seems likely that the realised throughput would slightly increase. The reason for this is that [possible solution 1](#Possible-Solutions) would eliminate forks caused by 1 second propagation delays which currently are wasted throughput. + - Possible solution 1 also involves adjusting other parameters so that the target rate of block production remains unchanged. Actually, it seems likely that the realised throughput would slightly increase. The reason for this is that [possible solution 1](#Possible-Solutions) would eliminate forks caused by 1 second propagation delays which currently are wasted throughput. 5. If my pool is located close to the majority then I am benefitting from this unfairness so why should I vote for this to be fixed? - -- See section: [Goals](#Goals). Hopefully most people in Cardano want to build a fair system for everyone no matter where they live. + - See section: [Goals](#Goals). Hopefully most people in Cardano want to build a fair system for everyone no matter where they live. ## Copyright This CIP is licensed under [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/legalcode). From 8d96ae15091098bdc7c39bed82f69ec524b2f526 Mon Sep 17 00:00:00 2001 From: Terminada Date: Tue, 3 Dec 2024 23:40:43 +1000 Subject: [PATCH 06/15] Update CPS-XXXX/README.md Co-authored-by: Robert Phair --- CPS-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 018ba2f75..51cbd01bc 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -1,6 +1,6 @@ --- CPS: ? -Title: Ouroboros not accounting for typical global network delays causes centralisation +Title: Block Delay Centralisation Status: Open Category: ? Authors: From 2bfbc81ea1a876e7c3c09ea51911ede883b8b772 Mon Sep 17 00:00:00 2001 From: Terminada Date: Tue, 3 Dec 2024 23:40:55 +1000 Subject: [PATCH 07/15] Update CPS-XXXX/README.md Co-authored-by: Robert Phair --- CPS-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 51cbd01bc..8d41e5c6a 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -2,7 +2,7 @@ CPS: ? Title: Block Delay Centralisation Status: Open -Category: ? +Category: Consensus Authors: - Terminada Proposed Solutions: [] From 8381ac1ccb0c0a4d2c55a979030d4779df9860c2 Mon Sep 17 00:00:00 2001 From: Terminada Date: Tue, 3 Dec 2024 23:41:52 +1000 Subject: [PATCH 08/15] Update CPS-XXXX/README.md Co-authored-by: Robert Phair --- CPS-XXXX/README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 8d41e5c6a..1b980cf28 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -8,6 +8,7 @@ Authors: Proposed Solutions: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/943 + - https://forum.cardano.org/t/problem-with-increasing-blocksize-or-processing-requirements/140044 Created: 2024-10-22 License: CC-BY-4.0 --- From c63ce0d2f4b54e23a74ccdd89d28d8bb5d7acd20 Mon Sep 17 00:00:00 2001 From: builder Date: Wed, 4 Dec 2024 00:46:51 +1000 Subject: [PATCH 09/15] Added example --- CPS-XXXX/README.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 1b980cf28..3110c2d69 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -31,6 +31,23 @@ Even the high quality infrastructure of a first world country like Australia is Considering that most stake pools are competing over 1% or less in fees, these are big numbers. The obvious solution for the remote pool is to move its block producer to a server housed in USA or Europe. This illustrates not only the centralisation problem created, but also the reduction in security that flows from running a block producer on someone elses computing hardware. +## Example +This block was produced by my locally controlled block producer in Australia. [It was a full block 86.57kB in size, containing 64 transactions, and 66.17kB of scripts]() + +These are the delays (from beginning of the slot) before each of _my own relays_ included this block in their chains by extending their tips: + +- Relay 1 (ARM on same LAN) --> Delayed=0.263s +- Relay 2 (AMD on adjacent LAN) --> Delayed=0.243s +- Relay 3 (ARM approx 5 Km away) --> Delayed=0.288s +- Relay 4 (AMD Contabo vps in USA) --> Delayed=2.682s +- Relay 5 (ARM Netcup vps in USA) --> Delayed=1.523s + +The above block delay values were obtained using [this script]() running on each relay. + +The [average propagation delay by nodes pinging such data to pooltool was 1.67 seconds]() + +Fortunately on this occasion no other block producer was leader for the subsequent slot. But, if there had been they probably would not have received my block in time and consequently would have produced their block upon the previous one creating a fork. + ## Goals Cardano should live up to its [11 blockchain tenets]() proposed by Prof Aggelos Kiayias, in particular T8 and T11 which speak to treating participants fairly without asymmetries. From b131ea2ca6b95d5b840d642d4c168bfb6806e1b4 Mon Sep 17 00:00:00 2001 From: builder Date: Wed, 4 Dec 2024 22:12:45 +1000 Subject: [PATCH 10/15] Extra examples and argument against --- CPS-XXXX/README.md | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 3110c2d69..e29b23b05 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -31,8 +31,8 @@ Even the high quality infrastructure of a first world country like Australia is Considering that most stake pools are competing over 1% or less in fees, these are big numbers. The obvious solution for the remote pool is to move its block producer to a server housed in USA or Europe. This illustrates not only the centralisation problem created, but also the reduction in security that flows from running a block producer on someone elses computing hardware. -## Example -This block was produced by my locally controlled block producer in Australia. [It was a full block 86.57kB in size, containing 64 transactions, and 66.17kB of scripts]() +## Examples +1. This block was produced by my locally controlled block producer in Australia. [It was a full block 86.57kB in size, containing 64 transactions, and 66.17kB of scripts]() These are the delays (from beginning of the slot) before each of _my own relays_ included this block in their chains by extending their tips: @@ -48,6 +48,16 @@ The [average propagation delay by nodes pinging such data to pooltool was 1.67 s Fortunately on this occasion no other block producer was leader for the subsequent slot. But, if there had been they probably would not have received my block in time and consequently would have produced their block upon the previous one creating a fork. +Note that this example is worse than average. Maybe the general internet was more congestion than usual on this occasion? [Pooltool reports the following average propagation delays for TERM pool](): +- Producer = 1.141s +- Receiver = 0.722s + +2. [Last block produced by TERM pool - Australia]() - [pooltool average propagation time = 1.38s]() + +3. [Last block produced by JSP pool - Japan]{) - [pooltool average propagation = 1.08s]() + +4. [Last block produced by AICHI pool - Japan]() - [pooltool average propagation = 1.55s]() + ## Goals Cardano should live up to its [11 blockchain tenets]() proposed by Prof Aggelos Kiayias, in particular T8 and T11 which speak to treating participants fairly without asymmetries. @@ -73,19 +83,22 @@ Cardano should live up to its [11 blockchain tenets]( Date: Wed, 4 Dec 2024 22:28:46 +1000 Subject: [PATCH 11/15] fix typo --- CPS-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index e29b23b05..df57a2bd6 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -54,7 +54,7 @@ Note that this example is worse than average. Maybe the general internet was mo 2. [Last block produced by TERM pool - Australia]() - [pooltool average propagation time = 1.38s]() -3. [Last block produced by JSP pool - Japan]{) - [pooltool average propagation = 1.08s]() +3. [Last block produced by JSP pool - Japan]() - [pooltool average propagation = 1.08s]() 4. [Last block produced by AICHI pool - Japan]() - [pooltool average propagation = 1.55s]() From e7bf9b4c103f3841f2d8364e78905c1183ee9526 Mon Sep 17 00:00:00 2001 From: builder Date: Wed, 4 Dec 2024 22:32:04 +1000 Subject: [PATCH 12/15] fix formatting --- CPS-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index df57a2bd6..4b07c69a0 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -99,7 +99,7 @@ Cardano should live up to its [11 blockchain tenets]( Date: Wed, 4 Dec 2024 22:56:21 +1000 Subject: [PATCH 13/15] Example of fork battle --- CPS-XXXX/README.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 4b07c69a0..3f969d438 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -52,11 +52,13 @@ Note that this example is worse than average. Maybe the general internet was mo - Producer = 1.141s - Receiver = 0.722s -2. [Last block produced by TERM pool - Australia]() - [pooltool average propagation time = 1.38s]() +2. [2nd last block produced by TERM pool - Australia]() - [pooltool average propagation time = 1.38s]() -3. [Last block produced by JSP pool - Japan]() - [pooltool average propagation = 1.08s]() +3. [Last block produced by TERM pool - Australia]() resulted in a "fork battle". Note that pooltool reported the average propagation time for this TERM block at 0.87s. IOGP pool was leader for the next slot but it obviously did not receive the TERM block in time and consequently produced its block upon the previous creating a fork. Unfortunately for TERM pool IOGP pool's block had the lower VRF value so it won the "fork battle" and TERM pool's block was orphaned. -4. [Last block produced by AICHI pool - Japan]() - [pooltool average propagation = 1.55s]() +4. [Last block produced by JSP pool - Japan]() - [pooltool average propagation = 1.08s]() + +5. [Last block produced by AICHI pool - Japan]() - [pooltool average propagation = 1.55s]() ## Goals Cardano should live up to its [11 blockchain tenets]() proposed by Prof Aggelos Kiayias, in particular T8 and T11 which speak to treating participants fairly without asymmetries. From 2eff5b16b14b818fb51d0c57563642abe1c80227 Mon Sep 17 00:00:00 2001 From: TerminadaDRep Date: Thu, 5 Dec 2024 00:03:58 +1000 Subject: [PATCH 14/15] Fix email address --- CPS-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 3f969d438..24cb06645 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -4,7 +4,7 @@ Title: Block Delay Centralisation Status: Open Category: Consensus Authors: - - Terminada + - Terminada Proposed Solutions: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/943 From d9ec47aba7f90e4a7219c6c911613e5d204b23f2 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Wed, 11 Dec 2024 00:13:57 +0530 Subject: [PATCH 15/15] likely only possible changes will be in network behaviour (not consensus) --- CPS-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-XXXX/README.md b/CPS-XXXX/README.md index 24cb06645..9619582a6 100644 --- a/CPS-XXXX/README.md +++ b/CPS-XXXX/README.md @@ -2,7 +2,7 @@ CPS: ? Title: Block Delay Centralisation Status: Open -Category: Consensus +Category: Network Authors: - Terminada Proposed Solutions: []