From 4fa35d1b69841578aae3568314db15430c5d7f9a Mon Sep 17 00:00:00 2001 From: ia Date: Mon, 9 May 2022 11:12:35 -0700 Subject: [PATCH 01/18] init draft of tabs proposal, q&a mostly Signed-off-by: ia --- _specs/ecip-tabs.md | 130 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 _specs/ecip-tabs.md diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md new file mode 100644 index 000000000..0387f073b --- /dev/null +++ b/_specs/ecip-tabs.md @@ -0,0 +1,130 @@ +# TABS ECIP + +- depends on AHA (which facilitates a new, critical characteristic: chain state dependent transactions) +- +- --- +- +- # Abstract +- +- # Motivation +- +- The work that currently drives the Ethereum Classic blockchain represents a minority of the work available (to it) globally. +- The blockchain's expected characteristic 'finality' (or "consistency") is diminished because of this situation. +- Double-spend attacks are a perpetually looming, disconcerting potential. +- Expectations of chain state finality are heuristically visible as transactional confirmation delay intervals. +- The magnitude of confirmation delay expresses an absence of confidence for the segment spanned. +- +- This proposal seeks to ameliorate this circumstance by increasing the cost of producing a competitive chain segment in private. +- It aims to maintain all existing assumptions and incentives associated with the incumbent proof-of-work protocol. +- +- # Specification +- +- +- +- +- # Rationale +- +- +- ### What happens if no one uses chain state exclusive transactions? +- +- The AHA proposal does not define any demand on the use of that transaction type. +- As such, it may be that transactors on the public chain do not make use of it, or use it with distant chain state references. +- +- The rate at which a private chain cannot include transactions available to the public chain determines the relative, differential finality expectation. +- +- If AHA is unused or otherwise does not express exclusive demands on chain state, the marginal augmentation of expected state finality under TABS diminishes, +- approaching the expectations incumbent under the proof-of-work protocol without it. +- +- AHA is NOT the only mechanism that could be used to implement chain state exclusivity for transactions. +- For example, if we explore a thought experiment where the global transaction pool has become disused, +- and in its place convention has become direct-to-miner publication of transactions (say, via email) and that, +- by an incentivized convention, miners do not share their available transactions freely with one another, +- then those "direct-message" transactions will not be available for inclusion on the attacker's chain. +- +- ### Are richer miners rewarded preferentially? +- +- Yes, but probably only marginally. +- +- Richer miners are preferred as a function of the determining factors of probably infrequent tie-break scenarios. +- Assume: Unequal distribution of capital between miners (richness, poorness). +- Assume: Randomness in global transaction pool availability. TODO: What distribution? Normal? Whats the variance? Exponential? +- +- ### How should miners sort transactions? +- +- If blocks are not full (block space is not scarce), then sorting is a moot point. Include all of them. +- +- Sorting by balance can yield a sometimes-higher expectation of canonical status; on which miner revenues depend. +- Miner revenues also depend on transaction fees. +- +- If the expected benefit (profit) from an additional marginal probability of canonicalization offered by a balance-sort exceeds the marginal losses in transaction fees, +- then the miner should sort by balance. Otherwise, they should continue to sort by fee. +- +- To the extent that the transaction pool offers unpredictable and variable aggregate balances, incentive to sort by balance is reduced. +- +- In most cases, the earnest race to discover and publish block solutions will easily outpace any marginal gains offered by balance-based transaction sorting. +- +- It is important to note that the incumbent protocol does not define a sort order: it is left to the market, to the presumed classically-greedy capitalistic whims of the miners and the developers who build defaults. +- A transaction sort order cannot be adequately defined by the availability of transactions (the "global" transaction pool) to miners is not guaranteed nor within the scope of the consensus-facing protocol. +- Thus, any model or algorithm this proposal provides in this regard should be considered only as an approach to a probably-sane default for an optimization problem, rather than a any demand on validity. +- +- TODO +- +- Naive?: +- If blocks are full, then sort by balance while pending TABS score is below that of the parent block. +- If the balances of all available transactions are insufficient to push the TABS value up, use fee sorting instead. +- Problem?: +- This explanation does not have the probability math, and it needs it. +- +- ### Will miners "stuff" blocks with their own transactions? +- +- We assume a (some) miner controls some finite amount of capital as blockchain currency (ie balance). +- In the cases where a miner is incentivized to include a self-signed transaction activating their own balance in a block they author, +- one transaction is theoretically sufficient. +- The use of more than sufficient transactions for the purpose is inefficient (and thus disincentivized) because, attributable to the block gas limit, +- they do so at the expense of cannibalizing space (and time) for a revenue-producing transaction. +- +- So: Indeed, they may "stuff" blocks with transactions of their own, but they expect to profit most +- by using only one transaction (using the least amount of gas) per block. +- +- ### How much is finality improved? +- +- Finality is measured as the expected likelihood of some state being eventually and ultimately permanent. +- +- In the case of a double-spend scenario, the incumbent cost of an attack (ie. a 51% attack) is the cost of capital available to provide the necessary proof-of-work solutions. +- TABS augments this cost by the aggregated balances of the senders of all exclusive transactions in the contending, public blocks. +- If the `gasLimit` is `10_000_000` and the average transaction requires `30000` gas, then a block will fit 333 transactions. +- We define an assumption that the average balance of a transaction sender address is `10ETC`. +- We assume that _all_ of these transactions define chain state dependencies concurrent with the contentious chain segment in question. +- Under these assumptions, the cost of a viable attack is increased by `333 * 10ETC = 3330ETC + epsilon`. +- +- If we modify the assumptions to use a 50% rate of relevant chain-state exclusive transactions (ie. 50% adoption and relevant use of AHA), +- the value becomes `333 * 10ETC * 0.5 = 1665ETC + epsilon`. +- +- It is noteworthy that this additional cost does not represent "spent" capital, rather _available_ capital. +- If the required capital is available to an attacker and yet the attack is not successful, the balance capital is recovered while the proof-of-work capital is not. +- An attacker must have _access_ to this additional capital, but does not have to actually part with it. +- +- ### Are there known vulnerabilities introduced? +- +- TABS Poisoning +- +- The attacker attempts to cause the public chain's TABS score to drop by filling the public transaction pool with high-fee, low-balance transactions. +- +- +- # Tests +- +- --- +- +- > Internal: scratch, drafts, questions, feedback below... +- +- # Scratch +- +- # Drafts +- +- # Q&A +- +- # Feedback +- +- +- +- From 8ca2ea68d70e881c50f3fab9a170256a50dbe201 Mon Sep 17 00:00:00 2001 From: ia Date: Thu, 19 May 2022 10:03:20 -0700 Subject: [PATCH 02/18] copy-paste from hackmd Signed-off-by: ia --- _specs/ecip-tabs.md | 431 +++++++++++++++++++++++++++++++------------- 1 file changed, 301 insertions(+), 130 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 0387f073b..06ac7ef6e 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -1,130 +1,301 @@ -# TABS ECIP - -- depends on AHA (which facilitates a new, critical characteristic: chain state dependent transactions) -- -- --- -- -- # Abstract -- -- # Motivation -- -- The work that currently drives the Ethereum Classic blockchain represents a minority of the work available (to it) globally. -- The blockchain's expected characteristic 'finality' (or "consistency") is diminished because of this situation. -- Double-spend attacks are a perpetually looming, disconcerting potential. -- Expectations of chain state finality are heuristically visible as transactional confirmation delay intervals. -- The magnitude of confirmation delay expresses an absence of confidence for the segment spanned. -- -- This proposal seeks to ameliorate this circumstance by increasing the cost of producing a competitive chain segment in private. -- It aims to maintain all existing assumptions and incentives associated with the incumbent proof-of-work protocol. -- -- # Specification -- -- -- -- -- # Rationale -- -- -- ### What happens if no one uses chain state exclusive transactions? -- -- The AHA proposal does not define any demand on the use of that transaction type. -- As such, it may be that transactors on the public chain do not make use of it, or use it with distant chain state references. -- -- The rate at which a private chain cannot include transactions available to the public chain determines the relative, differential finality expectation. -- -- If AHA is unused or otherwise does not express exclusive demands on chain state, the marginal augmentation of expected state finality under TABS diminishes, -- approaching the expectations incumbent under the proof-of-work protocol without it. -- -- AHA is NOT the only mechanism that could be used to implement chain state exclusivity for transactions. -- For example, if we explore a thought experiment where the global transaction pool has become disused, -- and in its place convention has become direct-to-miner publication of transactions (say, via email) and that, -- by an incentivized convention, miners do not share their available transactions freely with one another, -- then those "direct-message" transactions will not be available for inclusion on the attacker's chain. -- -- ### Are richer miners rewarded preferentially? -- -- Yes, but probably only marginally. -- -- Richer miners are preferred as a function of the determining factors of probably infrequent tie-break scenarios. -- Assume: Unequal distribution of capital between miners (richness, poorness). -- Assume: Randomness in global transaction pool availability. TODO: What distribution? Normal? Whats the variance? Exponential? -- -- ### How should miners sort transactions? -- -- If blocks are not full (block space is not scarce), then sorting is a moot point. Include all of them. -- -- Sorting by balance can yield a sometimes-higher expectation of canonical status; on which miner revenues depend. -- Miner revenues also depend on transaction fees. -- -- If the expected benefit (profit) from an additional marginal probability of canonicalization offered by a balance-sort exceeds the marginal losses in transaction fees, -- then the miner should sort by balance. Otherwise, they should continue to sort by fee. -- -- To the extent that the transaction pool offers unpredictable and variable aggregate balances, incentive to sort by balance is reduced. -- -- In most cases, the earnest race to discover and publish block solutions will easily outpace any marginal gains offered by balance-based transaction sorting. -- -- It is important to note that the incumbent protocol does not define a sort order: it is left to the market, to the presumed classically-greedy capitalistic whims of the miners and the developers who build defaults. -- A transaction sort order cannot be adequately defined by the availability of transactions (the "global" transaction pool) to miners is not guaranteed nor within the scope of the consensus-facing protocol. -- Thus, any model or algorithm this proposal provides in this regard should be considered only as an approach to a probably-sane default for an optimization problem, rather than a any demand on validity. -- -- TODO -- -- Naive?: -- If blocks are full, then sort by balance while pending TABS score is below that of the parent block. -- If the balances of all available transactions are insufficient to push the TABS value up, use fee sorting instead. -- Problem?: -- This explanation does not have the probability math, and it needs it. -- -- ### Will miners "stuff" blocks with their own transactions? -- -- We assume a (some) miner controls some finite amount of capital as blockchain currency (ie balance). -- In the cases where a miner is incentivized to include a self-signed transaction activating their own balance in a block they author, -- one transaction is theoretically sufficient. -- The use of more than sufficient transactions for the purpose is inefficient (and thus disincentivized) because, attributable to the block gas limit, -- they do so at the expense of cannibalizing space (and time) for a revenue-producing transaction. -- -- So: Indeed, they may "stuff" blocks with transactions of their own, but they expect to profit most -- by using only one transaction (using the least amount of gas) per block. -- -- ### How much is finality improved? -- -- Finality is measured as the expected likelihood of some state being eventually and ultimately permanent. -- -- In the case of a double-spend scenario, the incumbent cost of an attack (ie. a 51% attack) is the cost of capital available to provide the necessary proof-of-work solutions. -- TABS augments this cost by the aggregated balances of the senders of all exclusive transactions in the contending, public blocks. -- If the `gasLimit` is `10_000_000` and the average transaction requires `30000` gas, then a block will fit 333 transactions. -- We define an assumption that the average balance of a transaction sender address is `10ETC`. -- We assume that _all_ of these transactions define chain state dependencies concurrent with the contentious chain segment in question. -- Under these assumptions, the cost of a viable attack is increased by `333 * 10ETC = 3330ETC + epsilon`. -- -- If we modify the assumptions to use a 50% rate of relevant chain-state exclusive transactions (ie. 50% adoption and relevant use of AHA), -- the value becomes `333 * 10ETC * 0.5 = 1665ETC + epsilon`. -- -- It is noteworthy that this additional cost does not represent "spent" capital, rather _available_ capital. -- If the required capital is available to an attacker and yet the attack is not successful, the balance capital is recovered while the proof-of-work capital is not. -- An attacker must have _access_ to this additional capital, but does not have to actually part with it. -- -- ### Are there known vulnerabilities introduced? -- -- TABS Poisoning -- -- The attacker attempts to cause the public chain's TABS score to drop by filling the public transaction pool with high-fee, low-balance transactions. -- -- -- # Tests -- -- --- -- -- > Internal: scratch, drafts, questions, feedback below... -- -- # Scratch -- -- # Drafts -- -- # Q&A -- -- # Feedback -- -- -- -- +--- +ecip: 110x +title: TD*TABS Consensus Arbitration +author: Isaac (https://github.com/whilei) +discussions-to: TODO +status: Draft +type: Standards Track +category: Core +created: 2022-04-20 +requires: EIP-100, ECIP-1105 +lang: en +--- + +# Abstract + +Use a heuristic of chain state capitalization as an augmentive factor in consensus arbitration to improve normal finality rates and increase the cost of private chain production. + +# Motivation + +## State Finality Is Low and Slow + +![](https://i.imgur.com/c2biCLD.png) + +This proposal intends to increase the cost of producing a private, competitive chain segment, which is characteristic of double-spend attacks. It aims to improve finality expectations. + +It aims to maintain all existing assumptions and incentives associated with the incumbent proof-of-work protocol. + +# Specification + +This specification is defined as a modification of the general,[^1] currently existing canon-arbitration algorithm, namely "Modified GHOST," currently in use on Ethereum and Ethereum Classic networks. + +[^1]: Difficulty bomb and/or delay features are ignored. + +## TABS: Total Active Balance Synthesis + +Total Active Balance Synthesis (TABS) is a positive scalar integer. Generally considered, it provides a measure of currency capitalization over time for some chain state. + +It is defined to approach the median aggregate balance of all transaction-originating accounts for a blockchain of some length. It is denominated in Wei. + +TABS is a "synthetic" value derived from a "raw" Total Active Balance (TAB) value of any block and, recursively, the TABS value of its parent block, much like block difficulty and gas limit. + +### TAB: Total Active Balance + +The TAB value of a block is the sum of the balances (at the parent block state) of all unique transaction senders in the current block. + +Pseudo-code is provided as: + +```go +// blockTab returns the "raw" TAB value for a block. +// This value is the sum of the balances (at the parent state) +// of all transaction senders in this block. +func blockTab(block *Block) (tab *big.Int) { + + // uniqueSenders is a lookup to de-dupe sender accounts. + // Each sender account only gets counted once. + var uniqueSenders = make(map[common.Address]bool) + + // Iterate all transactions in the block + for _, tx := range block.transactions { + var _, seen = uniqueSenders[tx.sender] + if !seen { + uniqueSenders[tx.sender] = true + tab += state.balance(tx.sender, block.parentHash) + } + } + return tab +} +``` + +### TABS Adjustment Algorithm (Validation) + +The TABS value is defined as follows. + +A __minimum value__ _K_ for TABS is defined as `128e18` Wei, equivalent to 128 Ether. + +An __adjustment denominator__ _r_ is defined as `4096`. + +An __adjustment numerator__ _y_ is defined to be in the set `[-1,0,1]`, where: + + - `y = -1` if TAB(Bn) < TABS(Bn-1) + - `y = 0` if TAB(Bn) == TABS(Bn-1) + - `y = 1` if TAB(Bn) > TABS(Bn-1) + +From these definitions, the TABS algorithm for a block numbered _n_, written as TABS(Bn), is as follows: + +- if TABS(Bn-1) is undefined, then TABS(Bn) = _K_ +- otherwise, TABS(Bn) = MAX(K, TABS(Bn-1) + (y * TABS(Bn-1) // r)) + +Where `//` means floor division. + +Pseudo-code is provided as: + +```go +var minimumTABS = 128e18 +var tabsAdjustmentDenominator = 4096 + +// blockTABS returns the TABS value of currentBlock. +func blockTABS(parentBlock, currentBlock *Block) (tabs *big.Int) { + if parentBlock.tabs == nil { + return minimumTABS + } + + // tab is the "raw" 'Total Active Balance' value. + // This is the sum of the balances of all transaction senders + // in this block. + var tab = blockTab(currentBlock) + + var numerator *big.Int + if tab > parentBlock.tabs { + numerator = 1 + } else if tab < parentBlock.tabs { + numerator = -1 + } else { + numerator = 0 + } + + // 1 + 4096 => 4097 (4097/4096) + // 0 + 4096 => 4096 (4096/4096=1) + // -1 + 4096 => 4095 (4095/4096) + numerator += tabsAdjustmentDenominator + + // Return the adjusted parent block TABS, respecting + // the minimum 'floor' value, eg. + // 4097/4096 * parent.tabs + // 4096/4096 * parent.tabs + // 4095/4096 * parent.tabs + tabs = parent.tabs * numerator / tabsAdjustmentDenominator + + if tabs < minimumTABS { + return minimumTABS + } + return tabs +} +``` + +This algorithm is expected to yield a value which approaches the blockchain's median TAB score. + +## Consensus Score + +The incumbent primary "consensus score" is total difficulty. This value is defined as the sum of block difficulties for all blocks in some segment, as: + +```go +var consensusScore *big.Int +for _, block := range blocks { + consensusScore += block.difficulty +} +``` + +This proposal modifies the consensus score attribution as: + +```go +var consensusScore *big.Int +for _, block := range blocks { + consensusScore += block.difficulty * block.tabs +} +``` + +In this context, this proposal changes the atomic block consensus score value from block difficulty to the multiplicative product of block difficulty and block TABS. + +Like total difficulty, this value is still summed across a chain segment of any length to yield a total consensus score value. + +With this syntax, both the current and proposed arbitration conditions are defined to prefer any chain state with the greatest "consensus score." + + +## Invariance of Adjacent Canon-Arbitration Conditions + +Like the incumbent Total Difficulty comparison condition, the proposed condition replacing it ("Consensus Score") can yield indecisive outcomes, or ties. + +In the case of ties, subsequent protocol canon-arbitration conditions are preserved as invariants, namely (and in this order): + +- lesser block height preferred (objective) +- selfish authorship preferred (subjective) +- random coin toss (subjective) + +# Rationale + +## Codependent Production-Race Characteristics + +PoW resilience against double-spend attacks depends on an assumption that no entity controls more than "51\%" of the network's hashrate over some time. + +The logic of this proposal depends on an additional assumption that no entity controls more than the network's TABS value in capital over some time. + +These assumptions are codependent. If an entity is able to break either of these assumptions, normal finality expectations are invalidated. + +For example, the rate at which an entity controls more than the network's TABS for some time would lessen the demand on their relative control of hashrate for the same period. For example, exceeding the network's TABS score by 10\% for an hour might mean that an attack would demand only "45\%" relative hashrate to build a competitive chain segment in private. Likewise, the extent to which the attacker can beat the "51\%" hashrate demand lessens the demand on their required rate of available capital. + +## Block Space Opportunity Cost for Miners + +Miners can include "local" transactions on their own behalf at no currency cost, but at the opportunity cost of the inclusion of a revenue-generating transaction: cannibalism.[^2] + +[^2]: :dragon: This changes with EIP-1559 or other transaction burn-fee schemes. + +Miner participation in the TABS competition is expected, since expected block revenues are driven, in part, by the competitiveness of the capital they represent on their own behalf. + +Since a miner can and should (optimally) represent their capital as a single transaction in the blocks they mine, they are expected to at least sometimes cannibalize one balance-transfer transaction's worth of block space (the minimum, currently `21,000 / ~10,000,000 = 0.02%`) in their own interest. + +PS. No they don't have to actually send any balance to anyone. Just a signed transaction to themselves, for example, where they recoup the gas fee (as the credited coinbase) or charge themselves a zero gas price. + +## Short-Term Finality Rate Increases + +The rate of the network's production of orphan blocks (sometimes recorded as uncles) is expected to drop because the expected rate of objectively decidable (non-tie, "asymmetric") block competitions is expected to rise by around 50\%. The precise value of this expecation depends on the distribution of miner-available capital rates relative to the distribution of miner hashrates. + +Lessening the production rate of non-canonical blocks is, by definition, an increase in expected network state finality. + +## Conservative Adjustment Rate + +> An __adjustment denominator__ _r_ is defined as `4096`. + +An adjustment factor of `1/4096` is chosen relative to the incumbent minimum difficulty adjustment factor which is `1/2048`, and represents an intentionally conservative impact on chain production race probabilities and incentives. + +This is conservative because, for example, a block produced in the `[1-8] second` interval (`2049/2048*parent.difficulty`) with a diminished TABS value (`4095/4096*parent.TABS`) yields an equivalent overall consensus score (`+1/4096`) compared with a block produced in the next `[9-17] second` interval (`2048/2048*parent.difficulty`) with an increased TABS value (`4097/4096*parent.TABS`) yielding also a consensus score increase of a proportional `+1/4096`. + +Further investigation and analysis is encouraged for alternative adjustment rates, eg. `128`. + +## Median-Seeking Adjustment Algorithm + +The proposed algorithm "synthesizing" TABS is an implementation of a median-seeking algorithm. + +From this, and by definition, we expect that eventually for some set of blocks, half will have TAB values above and half below the resulting TABS value. + +Further investigation and analysis is encouraged for alternative adjustment algorithms, eg. moving averages.[^3] + +[^3]: Another idea uses a count of sequential TABS drops (adjustments downward) to cause the TABS value to fall _faster_ when it is only (or usually) falling. + +## PoW Race Incentives are (Mostly) Maintained + +A miner with access to 90\% of the TABS capital cannot produce blocks in isolation competitively; their private chain's TABS score will drop to 90\% of the public TABS and they will need something like 55\% hashrate to compensate if they want to compete independently over time. + +So the rich (but not too-rich) miner must compete in the proof-of-work race, and whether or not they can exceed some parent block's TABS will depend on the aggregated TAB value of the public transactions pending block inclusion. + +Upon the discovery of a new block and its availability to the miner, the miner faces two strategies -- ORPHAN, or ADOPT -- and should choose the more probably profitable one. To ORPHAN the proposed block means they continue work toward a competitive sibling block. To ADOPT means they begin work toward a child block. + +If their balance is _insufficient_ to beat the TABS of the announced block, clearly the incentives of the incumbent PoW race are preserved as invariant and the miner chooses to ADOPT. This covers about 50\% of the cases. + +If their balance _is sufficient_ to beat the TABS of the announced block, how do they model their probabilities for the ORPHAN or ADOPT strategies? + +Since their expected TABS consensus score is differentially, at most, `+1/4096` of the proposed block, they can still achieve probabilistic equilibrium with the incumbent race given only `4095/4096` of the otherwise necessary hashrate (representing the likelihood of their PoW solution discovery). + +So, unless the miner has `"51%" * 4095/4096` of the hashrate, the best strategy is still to ADOPT. + + +## Observable, Domain-Specific Competition Drives Security + +Heuristics about PoW finality expectations depend on "chain external" variables, like universally (on- and off-network) available hashrate. For example, hashrate from another network, networks, or any other applicable technologic domain like computer gaming; the state of the art of the work itself; the applicable market(s) for electricity, etc. + +Unlike fuzzy estimates about (potentially) globally available hashrate relative to the PoW network in question, all of the functional TABS protocol parameters are observable as on-chain values, namely balance distribution and overall currency supply. + +## Soft (But Important) Dependence on Transaction/State Exclusivity + +An adjacent proposal "AHA Typed Transactions" is listed as a dependency, which should be understood as an encouraged, prototypical mechanism for developing a way for transactions to be dependent on some chain state at the transactor's discretion, and in expectation that this chain state (presumed to be a public one) is different than any hypothetical private state. + +The motivation for this is to encourage a difference of TAB values between public and private chain segments. Transactions which depend on a chain state exclusive to the public chain count differentially toward the aggregated public TABS value, which increases the cost of a double-spend attack. + +However, this is not completely theoretically necessary. + +Miners can include "local" transactions arbitrarily in blocks they mine (using existing and common APIs and clients). Transactions made in this way already meet the criteria for differentially exclusive transactions, albeit imperfectly, since their differential exclusivity ("locality") is limited to the pending block because the transactions, once published in the public chain state, become available to any competitor. + +TLDR; theoretically, existing APIs for "local" transactions can sufficiently differentially benefit the public state, but can do so only to the differential magnitude of a single block, and, as such, are practically insufficient. + +# Tests + +## Simulation Programs + +I have written a couple programs that I've used to simulate and observe chain production. + +- `go-miner-sim` simulates PoW/TABS production. +- `go-block-step` simulates an abstracted version of block production (a single case). Helps me with statistics. + +I would love review, feedback, and collaboration on these. + +## Empirical Context + +TAB and TABS values can be derived retrospectively for Ethereum and Ethereum Classic chains. + +At the time of writing, and with limited sample sizes, I estimate TABS values as follows. + +- Ethereum's (ETH): ~500,000 ETH. +- Ethereum Classic's (ETC): ~7,000 ETC. + +Further efforts toward current or retrospective analysis of real-life PoW chains, not limited to ETC, is welcome. + +# Backwards Compatibility + +A hard fork would be required. + +# Known Vulnerabilities + +## TABS Poisoning + +An attacker could promote high-gas, low-balance transactions in the public pool, attempting to lessen the public TABS value for some time. + +This strategy would be observable in real time by the public. + +## Whales and Collusive Capital + +An attacker could challenge the assumption that no entity controls more than the public TABS value for some time. + +This attack, like a PoW 51\% attack, would be invisible until published. + + + From ab9a2e28caeb9b8952c92b8bf28131c5a7f0d034 Mon Sep 17 00:00:00 2001 From: ia Date: Fri, 20 May 2022 11:20:50 -0700 Subject: [PATCH 03/18] :eyeglasses: :pen: Signed-off-by: ia --- _specs/ecip-tabs.md | 59 ++++++++++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 20 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 06ac7ef6e..fbede4670 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -1,6 +1,6 @@ --- ecip: 110x -title: TD*TABS Consensus Arbitration +title: A 2-Dimensional Consensus Arbitration Protocol, Difficulty * TABS author: Isaac (https://github.com/whilei) discussions-to: TODO status: Draft @@ -13,7 +13,7 @@ lang: en # Abstract -Use a heuristic of chain state capitalization as an augmentive factor in consensus arbitration to improve normal finality rates and increase the cost of private chain production. +Use a heuristic of chain state capitalization as an augmentive factor in consensus arbitration to improve normal finality rates and increase the cost of abnormal private chain production. # Motivation @@ -21,13 +21,11 @@ Use a heuristic of chain state capitalization as an augmentive factor in consens ![](https://i.imgur.com/c2biCLD.png) -This proposal intends to increase the cost of producing a private, competitive chain segment, which is characteristic of double-spend attacks. It aims to improve finality expectations. - -It aims to maintain all existing assumptions and incentives associated with the incumbent proof-of-work protocol. +This proposal intends to increase the cost of producing a private, competitive chain segment, which is characteristic of double-spend attacks. It aims to improve finality expectations by increasing the cost of attack, while maintaining existing assumptions and incentives associated with the incumbent proof-of-work protocol. # Specification -This specification is defined as a modification of the general,[^1] currently existing canon-arbitration algorithm, namely "Modified GHOST," currently in use on Ethereum and Ethereum Classic networks. +This specification is defined as a modification of the general,[^1] currently existing canon-arbitration algorithm, namely "Modified GHOST," currently in use on the Ethereum and Ethereum Classic networks. [^1]: Difficulty bomb and/or delay features are ignored. @@ -176,25 +174,46 @@ In the case of ties, subsequent protocol canon-arbitration conditions are preser ## Codependent Production-Race Characteristics -PoW resilience against double-spend attacks depends on an assumption that no entity controls more than "51\%" of the network's hashrate over some time. +PoW resilience against double-spend attacks depends on an assumption that no entity controls more than the "honest"/public network's hashrate over some time. + +The logic of this proposal depends on an _additional assumption_ that no entity controls more than the network's TABS value in capital over some time. + +These assumptions are codependent. If an entity is able to break either of these unit assumptions, the degree to which they are compromised is borne by the other unit. + + +```go +// Equilibrium Example Schema -The logic of this proposal depends on an additional assumption that no entity controls more than the network's TABS value in capital over some time. +// D: Difficulty +// S: TABS +// a, b, x, y: Coefficients +(a*D) * (b*S) = (x*D) * (y*S) +``` -These assumptions are codependent. If an entity is able to break either of these assumptions, normal finality expectations are invalidated. +For example, while maintaining an equivalence in consensus scores, a relatively greater difficulty value lessens the demand on TABS. +```go +var publicChainConsensusScore = (1*D) * (1*S) -For example, the rate at which an entity controls more than the network's TABS for some time would lessen the demand on their relative control of hashrate for the same period. For example, exceeding the network's TABS score by 10\% for an hour might mean that an attack would demand only "45\%" relative hashrate to build a competitive chain segment in private. Likewise, the extent to which the attacker can beat the "51\%" hashrate demand lessens the demand on their required rate of available capital. +// An attacker with 110% hashrate of the "honest"/public net +// needs 91% of the public TABS value to be competitive. +var attackChainConsensusScore_Hasher = (1.1*D) * (/*1.1/1=*/0.91*S) + +// An attacker with 91% hashrate of the "honest"/public net +// needs 110% of the public TABS value to be competitive. +var attackChainConsensusScore_Richer = (0.91*D) * (1.1*S) +``` ## Block Space Opportunity Cost for Miners -Miners can include "local" transactions on their own behalf at no currency cost, but at the opportunity cost of the inclusion of a revenue-generating transaction: cannibalism.[^2] +Miners can include "local" transactions on their own behalf at no currency cost, but at the opportunity cost of the inclusion of a revenue-generating transaction.[^2] [^2]: :dragon: This changes with EIP-1559 or other transaction burn-fee schemes. Miner participation in the TABS competition is expected, since expected block revenues are driven, in part, by the competitiveness of the capital they represent on their own behalf. -Since a miner can and should (optimally) represent their capital as a single transaction in the blocks they mine, they are expected to at least sometimes cannibalize one balance-transfer transaction's worth of block space (the minimum, currently `21,000 / ~10,000,000 = 0.02%`) in their own interest. +Since a miner can and should (optimally) represent their self-interested capital as a single transaction in the blocks they mine, they are expected to at least sometimes cannibalize one balance-transfer transaction's worth of block space (the minimum, currently `21,000 / ~10,000,000 = 0.02%`) in their own interest. -PS. No they don't have to actually send any balance to anyone. Just a signed transaction to themselves, for example, where they recoup the gas fee (as the credited coinbase) or charge themselves a zero gas price. +PS. No, miners don't have to actually send any balance to anyone. Just a signed transaction to themselves, for example, where they recoup the gas fee (as the credited coinbase) or charge themselves a zero gas price. ## Short-Term Finality Rate Increases @@ -218,13 +237,13 @@ The proposed algorithm "synthesizing" TABS is an implementation of a median-seek From this, and by definition, we expect that eventually for some set of blocks, half will have TAB values above and half below the resulting TABS value. -Further investigation and analysis is encouraged for alternative adjustment algorithms, eg. moving averages.[^3] +Further investigation and analysis is encouraged for alternative adjustment algorithms, eg. moving averages, sequential weights.[^3] [^3]: Another idea uses a count of sequential TABS drops (adjustments downward) to cause the TABS value to fall _faster_ when it is only (or usually) falling. ## PoW Race Incentives are (Mostly) Maintained -A miner with access to 90\% of the TABS capital cannot produce blocks in isolation competitively; their private chain's TABS score will drop to 90\% of the public TABS and they will need something like 55\% hashrate to compensate if they want to compete independently over time. +A miner with access to 90\% of the TABS capital cannot produce blocks in isolation competitively; their private chain's TABS score will drop to 90\% of the public TABS and they will need something like 110\% hashrate to compensate if they want to compete independently over time. So the rich (but not too-rich) miner must compete in the proof-of-work race, and whether or not they can exceed some parent block's TABS will depend on the aggregated TAB value of the public transactions pending block inclusion. @@ -241,7 +260,7 @@ So, unless the miner has `"51%" * 4095/4096` of the hashrate, the best strategy ## Observable, Domain-Specific Competition Drives Security -Heuristics about PoW finality expectations depend on "chain external" variables, like universally (on- and off-network) available hashrate. For example, hashrate from another network, networks, or any other applicable technologic domain like computer gaming; the state of the art of the work itself; the applicable market(s) for electricity, etc. +Heuristics about PoW finality expectations depend on "off-chain" variables, like universally (on- and off-network) available applicable hashrate. For example, hashrate from another network, networks, or any other applicable technologic domain like computer gaming; the state of the art of the work itself; the applicable market(s) for electricity, etc. Unlike fuzzy estimates about (potentially) globally available hashrate relative to the PoW network in question, all of the functional TABS protocol parameters are observable as on-chain values, namely balance distribution and overall currency supply. @@ -261,16 +280,16 @@ TLDR; theoretically, existing APIs for "local" transactions can sufficiently dif ## Simulation Programs -I have written a couple programs that I've used to simulate and observe chain production. +I have written a couple programs that I've used to simulate and observe chain production characteristics. - `go-miner-sim` simulates PoW/TABS production. -- `go-block-step` simulates an abstracted version of block production (a single case). Helps me with statistics. +- `go-block-step` simulates an abstracted version of the block production race. I would love review, feedback, and collaboration on these. ## Empirical Context -TAB and TABS values can be derived retrospectively for Ethereum and Ethereum Classic chains. +TAB and TABS value estimates can be derived retrospectively for Ethereum and Ethereum Classic chains. At the time of writing, and with limited sample sizes, I estimate TABS values as follows. @@ -295,7 +314,7 @@ This strategy would be observable in real time by the public. An attacker could challenge the assumption that no entity controls more than the public TABS value for some time. -This attack, like a PoW 51\% attack, would be invisible until published. +This attack, like a pure-PoW double-spend attack, would be invisible until published. From 910fb43a33baf567c46c74980c5628fda5e72512 Mon Sep 17 00:00:00 2001 From: ia Date: Fri, 20 May 2022 11:24:47 -0700 Subject: [PATCH 04/18] remove not-so-useful drawing of finality curves Signed-off-by: ia --- _specs/ecip-tabs.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index fbede4670..a6e4cb2c1 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -19,8 +19,6 @@ Use a heuristic of chain state capitalization as an augmentive factor in consens ## State Finality Is Low and Slow -![](https://i.imgur.com/c2biCLD.png) - This proposal intends to increase the cost of producing a private, competitive chain segment, which is characteristic of double-spend attacks. It aims to improve finality expectations by increasing the cost of attack, while maintaining existing assumptions and incentives associated with the incumbent proof-of-work protocol. # Specification From fd4ef14353ddc5dd75702140417d92732612da91 Mon Sep 17 00:00:00 2001 From: ia Date: Fri, 20 May 2022 11:27:18 -0700 Subject: [PATCH 05/18] :eyeglasses: :pen: Signed-off-by: ia --- _specs/ecip-tabs.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index a6e4cb2c1..6e52fbce9 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -42,10 +42,10 @@ The TAB value of a block is the sum of the balances (at the parent block state) Pseudo-code is provided as: ```go -// blockTab returns the "raw" TAB value for a block. +// blockTAB returns the "raw" TAB value for a block. // This value is the sum of the balances (at the parent state) // of all transaction senders in this block. -func blockTab(block *Block) (tab *big.Int) { +func blockTAB(block *Block) (tab *big.Int) { // uniqueSenders is a lookup to de-dupe sender accounts. // Each sender account only gets counted once. @@ -99,7 +99,7 @@ func blockTABS(parentBlock, currentBlock *Block) (tabs *big.Int) { // tab is the "raw" 'Total Active Balance' value. // This is the sum of the balances of all transaction senders // in this block. - var tab = blockTab(currentBlock) + var tab = blockTAB(currentBlock) var numerator *big.Int if tab > parentBlock.tabs { From 8a87babe51483e896284801e3993a22d138e563f Mon Sep 17 00:00:00 2001 From: ia Date: Mon, 23 May 2022 09:48:32 -0700 Subject: [PATCH 06/18] :hammer: Signed-off-by: ia --- _specs/ecip-tabs.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 6e52fbce9..27435928d 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -13,7 +13,7 @@ lang: en # Abstract -Use a heuristic of chain state capitalization as an augmentive factor in consensus arbitration to improve normal finality rates and increase the cost of abnormal private chain production. +Use a heuristic of chain state capitalization as a 2nd-dimension factor in consensus arbitration to improve normal finality rates and increase the cost of abnormal private chain production. # Motivation @@ -170,14 +170,13 @@ In the case of ties, subsequent protocol canon-arbitration conditions are preser # Rationale -## Codependent Production-Race Characteristics +## Inversely Proportional Equilibrium Factors -PoW resilience against double-spend attacks depends on an assumption that no entity controls more than the "honest"/public network's hashrate over some time. +PoW resilience against double-spend attacks depends on an assumption that no entity controls more than the "honest"/public network's hashrate over some time. The difficulty value over time represents an equilibrium value. Difficulty values over time in excess (or deficiency) of the equilbrium represent competitiveness; for good, or for evil. -The logic of this proposal depends on an _additional assumption_ that no entity controls more than the network's TABS value in capital over some time. - -These assumptions are codependent. If an entity is able to break either of these unit assumptions, the degree to which they are compromised is borne by the other unit. +The logic of this proposal depends on an _additional assumption_ that no entity controls more than the network's TABS value in capital over some time. This is another equilibrium value. +These assumptions (ie. equilibrium values) factored together create a 2-dimensional equilibrium. An excess or shortfall in one variable inversely slackens or raises the demand on the other for equilibrium. ```go // Equilibrium Example Schema @@ -211,7 +210,7 @@ Miner participation in the TABS competition is expected, since expected block re Since a miner can and should (optimally) represent their self-interested capital as a single transaction in the blocks they mine, they are expected to at least sometimes cannibalize one balance-transfer transaction's worth of block space (the minimum, currently `21,000 / ~10,000,000 = 0.02%`) in their own interest. -PS. No, miners don't have to actually send any balance to anyone. Just a signed transaction to themselves, for example, where they recoup the gas fee (as the credited coinbase) or charge themselves a zero gas price. +Miner-interest transactions can be inoperative. Miners don't have to actually send any balance to anyone. Just a signed transaction to themselves, for example, where they recoup the gas fee (as the credited coinbase) or charge themselves a zero gas price. ## Short-Term Finality Rate Increases @@ -233,7 +232,7 @@ Further investigation and analysis is encouraged for alternative adjustment rate The proposed algorithm "synthesizing" TABS is an implementation of a median-seeking algorithm. -From this, and by definition, we expect that eventually for some set of blocks, half will have TAB values above and half below the resulting TABS value. +From this, and by definition, we expect that eventually for some set of blocks, roughly half will have TAB values above, and half below the resulting TABS value. However, since the block authorship _per miner_ is not equally distributed, the TABS score will be weighted more heavily toward more prolific miners. The scale of this weighting will depend on the ratio of the aggregate balance of public transactions relative to any balance represented exclusively by some miner. Further investigation and analysis is encouraged for alternative adjustment algorithms, eg. moving averages, sequential weights.[^3] From 79fb7000ccedb4c3e31160deb3ec9a78aa6c0601 Mon Sep 17 00:00:00 2001 From: ia Date: Mon, 23 May 2022 10:12:04 -0700 Subject: [PATCH 07/18] :hammer: Signed-off-by: ia --- _specs/ecip-tabs.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 27435928d..9b0bfb9bf 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -224,7 +224,9 @@ Lessening the production rate of non-canonical blocks is, by definition, an incr An adjustment factor of `1/4096` is chosen relative to the incumbent minimum difficulty adjustment factor which is `1/2048`, and represents an intentionally conservative impact on chain production race probabilities and incentives. -This is conservative because, for example, a block produced in the `[1-8] second` interval (`2049/2048*parent.difficulty`) with a diminished TABS value (`4095/4096*parent.TABS`) yields an equivalent overall consensus score (`+1/4096`) compared with a block produced in the next `[9-17] second` interval (`2048/2048*parent.difficulty`) with an increased TABS value (`4097/4096*parent.TABS`) yielding also a consensus score increase of a proportional `+1/4096`. +The potential rates of change for difficulty are greater (faster) in all cases than those of TABS. + +For example, a block produced in the `[1-8] second` interval (`2049/2048*parent.difficulty`) with a diminished TABS value (`4095/4096*parent.TABS`) yields an equivalent overall consensus score (`+1/4096`) compared with a block produced in the next `[9-17] second` interval (`2048/2048*parent.difficulty`) with an increased TABS value (`4097/4096*parent.TABS`) yielding also a consensus score increase of a proportional `+1/4096`. Further investigation and analysis is encouraged for alternative adjustment rates, eg. `128`. @@ -236,7 +238,7 @@ From this, and by definition, we expect that eventually for some set of blocks, Further investigation and analysis is encouraged for alternative adjustment algorithms, eg. moving averages, sequential weights.[^3] -[^3]: Another idea uses a count of sequential TABS drops (adjustments downward) to cause the TABS value to fall _faster_ when it is only (or usually) falling. +[^3]: Another idea uses a count of sequential TABS drops (number of consecutive falling adjustments) to cause the TABS value to fall _faster_ when it is only (or usually) falling. ## PoW Race Incentives are (Mostly) Maintained @@ -279,7 +281,7 @@ TLDR; theoretically, existing APIs for "local" transactions can sufficiently dif I have written a couple programs that I've used to simulate and observe chain production characteristics. -- `go-miner-sim` simulates PoW/TABS production. +- [`go-miner-sim`](https://github.com/etclabscore/go-miner-sim) simulates PoW/TABS chain production in a multi-agent environment. - `go-block-step` simulates an abstracted version of the block production race. I would love review, feedback, and collaboration on these. @@ -309,7 +311,7 @@ This strategy would be observable in real time by the public. ## Whales and Collusive Capital -An attacker could challenge the assumption that no entity controls more than the public TABS value for some time. +An attacker could challenge the assumption that no entity controls more than the public TABS value for some time. The value of TABS relative to current supply and its account distribution informs this risk model. This attack, like a pure-PoW double-spend attack, would be invisible until published. From bd9a2d6950f1e99ccccc7d00cfba15566540e1eb Mon Sep 17 00:00:00 2001 From: ia Date: Mon, 23 May 2022 10:19:35 -0700 Subject: [PATCH 08/18] reorder sections to maybe make more sense together Signed-off-by: ia --- _specs/ecip-tabs.md | 53 +++++++++++++++++++++++---------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 9b0bfb9bf..2b7d2ab76 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -200,35 +200,41 @@ var attackChainConsensusScore_Hasher = (1.1*D) * (/*1.1/1=*/0.91*S) var attackChainConsensusScore_Richer = (0.91*D) * (1.1*S) ``` -## Block Space Opportunity Cost for Miners +## Conservative Adjustment Rate -Miners can include "local" transactions on their own behalf at no currency cost, but at the opportunity cost of the inclusion of a revenue-generating transaction.[^2] +> An __adjustment denominator__ _r_ is defined as `4096`. -[^2]: :dragon: This changes with EIP-1559 or other transaction burn-fee schemes. +An adjustment factor of `1/4096` is chosen relative to the incumbent minimum difficulty adjustment factor which is `1/2048`, and represents an intentionally conservative impact on chain production race probabilities and incentives. -Miner participation in the TABS competition is expected, since expected block revenues are driven, in part, by the competitiveness of the capital they represent on their own behalf. +The potential rates of change for difficulty are greater (faster) in all cases than those of TABS. -Since a miner can and should (optimally) represent their self-interested capital as a single transaction in the blocks they mine, they are expected to at least sometimes cannibalize one balance-transfer transaction's worth of block space (the minimum, currently `21,000 / ~10,000,000 = 0.02%`) in their own interest. +For example, a block produced in the `[1-8] second` interval (`2049/2048*parent.difficulty`) with a diminished TABS value (`4095/4096*parent.TABS`) yields an equivalent overall consensus score (`+1/4096`) compared with a block produced in the next `[9-17] second` interval (`2048/2048*parent.difficulty`) with an increased TABS value (`4097/4096*parent.TABS`) yielding also a consensus score increase of a proportional `+1/4096`. -Miner-interest transactions can be inoperative. Miners don't have to actually send any balance to anyone. Just a signed transaction to themselves, for example, where they recoup the gas fee (as the credited coinbase) or charge themselves a zero gas price. +Further investigation and analysis is encouraged for alternative adjustment rates, eg. `128`. -## Short-Term Finality Rate Increases +## PoW Race Incentives are (Mostly) Maintained -The rate of the network's production of orphan blocks (sometimes recorded as uncles) is expected to drop because the expected rate of objectively decidable (non-tie, "asymmetric") block competitions is expected to rise by around 50\%. The precise value of this expecation depends on the distribution of miner-available capital rates relative to the distribution of miner hashrates. +A miner with access to 90\% of the TABS capital cannot produce blocks in isolation competitively; their private chain's TABS score will drop to 90\% of the public TABS and they will need something like 110\% hashrate to compensate if they want to compete independently over time. -Lessening the production rate of non-canonical blocks is, by definition, an increase in expected network state finality. +So the rich (but not too-rich) miner must compete in the proof-of-work race, and whether or not they can exceed some parent block's TABS will depend on the aggregated TAB value of the public transactions pending block inclusion. -## Conservative Adjustment Rate +Upon the discovery of a new block and its availability to the miner, the miner faces two strategies -- ORPHAN, or ADOPT -- and should choose the more probably profitable one. To ORPHAN the proposed block means they continue work toward a competitive sibling block. To ADOPT means they begin work toward a child block. -> An __adjustment denominator__ _r_ is defined as `4096`. +If their balance is _insufficient_ to beat the TABS of the announced block, clearly the incentives of the incumbent PoW race are preserved as invariant and the miner chooses to ADOPT. This covers about 50\% of the cases. -An adjustment factor of `1/4096` is chosen relative to the incumbent minimum difficulty adjustment factor which is `1/2048`, and represents an intentionally conservative impact on chain production race probabilities and incentives. +If their balance _is sufficient_ to beat the TABS of the announced block, how do they model their probabilities for the ORPHAN or ADOPT strategies? -The potential rates of change for difficulty are greater (faster) in all cases than those of TABS. +Since their expected TABS consensus score is differentially, at most, `+1/4096` of the proposed block, they can still achieve probabilistic equilibrium with the incumbent race given only `4095/4096` of the otherwise necessary hashrate (representing the likelihood of their PoW solution discovery). -For example, a block produced in the `[1-8] second` interval (`2049/2048*parent.difficulty`) with a diminished TABS value (`4095/4096*parent.TABS`) yields an equivalent overall consensus score (`+1/4096`) compared with a block produced in the next `[9-17] second` interval (`2048/2048*parent.difficulty`) with an increased TABS value (`4097/4096*parent.TABS`) yielding also a consensus score increase of a proportional `+1/4096`. +So, unless the miner has `"51%" * 4095/4096` of the hashrate, the best strategy is still to ADOPT. -Further investigation and analysis is encouraged for alternative adjustment rates, eg. `128`. +## Short-Term Finality Rate Increases + +The rate of the network's production of orphan blocks (sometimes recorded as uncles) is expected to drop because the expected rate of objectively decidable (non-tie, "asymmetric") block competitions is expected to rise by around 50\%.[^4] The precise value of this expecation depends on the distribution of miner-available capital rates relative to the distribution of miner hashrates. + +[^4]: This assumes that the aggregated balances represented in TABS are not constant. If a TABS value (and the transaction-originating balances that compose it) is held constant, then the finality characteristics of the production race imitate pure-PoW exactly. + +Lessening the production rate of non-canonical blocks is, by definition, an increase in expected network state finality. ## Median-Seeking Adjustment Algorithm @@ -240,22 +246,17 @@ Further investigation and analysis is encouraged for alternative adjustment algo [^3]: Another idea uses a count of sequential TABS drops (number of consecutive falling adjustments) to cause the TABS value to fall _faster_ when it is only (or usually) falling. -## PoW Race Incentives are (Mostly) Maintained - -A miner with access to 90\% of the TABS capital cannot produce blocks in isolation competitively; their private chain's TABS score will drop to 90\% of the public TABS and they will need something like 110\% hashrate to compensate if they want to compete independently over time. - -So the rich (but not too-rich) miner must compete in the proof-of-work race, and whether or not they can exceed some parent block's TABS will depend on the aggregated TAB value of the public transactions pending block inclusion. - -Upon the discovery of a new block and its availability to the miner, the miner faces two strategies -- ORPHAN, or ADOPT -- and should choose the more probably profitable one. To ORPHAN the proposed block means they continue work toward a competitive sibling block. To ADOPT means they begin work toward a child block. +## Block Space Opportunity Cost for Miners -If their balance is _insufficient_ to beat the TABS of the announced block, clearly the incentives of the incumbent PoW race are preserved as invariant and the miner chooses to ADOPT. This covers about 50\% of the cases. +Miners can include "local" transactions on their own behalf at no currency cost, but at the opportunity cost of the inclusion of a revenue-generating transaction.[^2] -If their balance _is sufficient_ to beat the TABS of the announced block, how do they model their probabilities for the ORPHAN or ADOPT strategies? +[^2]: :dragon: This changes with EIP-1559 or other transaction burn-fee schemes. -Since their expected TABS consensus score is differentially, at most, `+1/4096` of the proposed block, they can still achieve probabilistic equilibrium with the incumbent race given only `4095/4096` of the otherwise necessary hashrate (representing the likelihood of their PoW solution discovery). +Miner participation in the TABS competition is expected, since expected block revenues are driven, in part, by the competitiveness of the capital they represent on their own behalf. -So, unless the miner has `"51%" * 4095/4096` of the hashrate, the best strategy is still to ADOPT. +Since a miner can and should (optimally) represent their self-interested capital as a single transaction in the blocks they mine, they are expected to at least sometimes cannibalize one balance-transfer transaction's worth of block space (the minimum, currently `21,000 / ~10,000,000 = 0.02%`) in their own interest. +Miner-interest transactions can be inoperative. Miners don't have to actually send any balance to anyone. Just a signed transaction to themselves, for example, where they recoup the gas fee (as the credited coinbase) or charge themselves a zero gas price. ## Observable, Domain-Specific Competition Drives Security From a18fc3f16765f906609402ad1abd2755fe31b6a9 Mon Sep 17 00:00:00 2001 From: ia Date: Mon, 23 May 2022 14:22:33 -0700 Subject: [PATCH 09/18] :eyeglasses: :pen: Signed-off-by: ia --- _specs/ecip-tabs.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 2b7d2ab76..987197c41 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -160,7 +160,7 @@ With this syntax, both the current and proposed arbitration conditions are defin ## Invariance of Adjacent Canon-Arbitration Conditions -Like the incumbent Total Difficulty comparison condition, the proposed condition replacing it ("Consensus Score") can yield indecisive outcomes, or ties. +Like the incumbent protocol's initial comparison condition on Total Difficulty, the comparison condition proposed to replace it (an abstracted "Consensus Score") can yield indecisive outcomes, or ties. In the case of ties, subsequent protocol canon-arbitration conditions are preserved as invariants, namely (and in this order): @@ -172,11 +172,11 @@ In the case of ties, subsequent protocol canon-arbitration conditions are preser ## Inversely Proportional Equilibrium Factors -PoW resilience against double-spend attacks depends on an assumption that no entity controls more than the "honest"/public network's hashrate over some time. The difficulty value over time represents an equilibrium value. Difficulty values over time in excess (or deficiency) of the equilbrium represent competitiveness; for good, or for evil. +PoW resilience against double-spend attacks depends on an assumption that no entity controls more than the "honest"/public network's hashrate over some time. So the respective difficulty values over time (eg. 44%/56%) are compared relative to an equilibrium value (50%/50%). Difficulty values over time in excess or deficiency of the equilbrium represent competitiveness; for good, or for evil. The logic of this proposal depends on an _additional assumption_ that no entity controls more than the network's TABS value in capital over some time. This is another equilibrium value. -These assumptions (ie. equilibrium values) factored together create a 2-dimensional equilibrium. An excess or shortfall in one variable inversely slackens or raises the demand on the other for equilibrium. +These assumptions (ie. equilibrium values) factored together create a 2-dimensional equilibrium. An excess or shortfall in one variable inversely and proportionally slackens or raises the demand on the other in maintenance of the 2-dimensional equilibrium. ```go // Equilibrium Example Schema From bf71258c3f46f0d0b839b8c48531422929266fe6 Mon Sep 17 00:00:00 2001 From: ia Date: Mon, 23 May 2022 15:53:03 -0700 Subject: [PATCH 10/18] working on new paragraphs about block/capital equations Signed-off-by: ia --- _specs/ecip-tabs.md | 52 ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 47 insertions(+), 5 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 987197c41..6d88f7d04 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -214,11 +214,9 @@ Further investigation and analysis is encouraged for alternative adjustment rate ## PoW Race Incentives are (Mostly) Maintained -A miner with access to 90\% of the TABS capital cannot produce blocks in isolation competitively; their private chain's TABS score will drop to 90\% of the public TABS and they will need something like 110\% hashrate to compensate if they want to compete independently over time. +The viability of a PoW-based network depends vitally on the competitiveness and fairness of the PoW race. Linearity (actually sublinearity) here is the goal; 1 GPU : 1 vote/gamble/point/token/whatever. -So the rich (but not too-rich) miner must compete in the proof-of-work race, and whether or not they can exceed some parent block's TABS will depend on the aggregated TAB value of the public transactions pending block inclusion. - -Upon the discovery of a new block and its availability to the miner, the miner faces two strategies -- ORPHAN, or ADOPT -- and should choose the more probably profitable one. To ORPHAN the proposed block means they continue work toward a competitive sibling block. To ADOPT means they begin work toward a child block. +Upon the availability of a potentially canonical block to some miner, they have two strategies: ORPHAN or ADOPT. Because we assume that greed is a reliable and optimal strategy, the miner should choose the more probably profitable option. To ORPHAN the proposed block means they continue work toward a competitive sibling block. To ADOPT means they begin work toward a child block. If their balance is _insufficient_ to beat the TABS of the announced block, clearly the incentives of the incumbent PoW race are preserved as invariant and the miner chooses to ADOPT. This covers about 50\% of the cases. @@ -226,7 +224,51 @@ If their balance _is sufficient_ to beat the TABS of the announced block, how do Since their expected TABS consensus score is differentially, at most, `+1/4096` of the proposed block, they can still achieve probabilistic equilibrium with the incumbent race given only `4095/4096` of the otherwise necessary hashrate (representing the likelihood of their PoW solution discovery). -So, unless the miner has `"51%" * 4095/4096` of the hashrate, the best strategy is still to ADOPT. +So, unless the miner has `"51%" * 4095/4096` of the hashrate, the best strategy is still to ADOPT. + +This tells us that the "51%" rule is no longer "50% + epsilon". It becomes "49.9878% + epsilon". + +### A Deeper Dive into Block Distribution vs. Capital Distribution + +As above, the viability of the game on which the network's state depends is hinged on the relationship of invested capital share to an expected and realized share in canonical block production. + +Empirically we are lead to believe that the distribution of Ethereum and Ethereum Classic's mining interests are long tail-type curves. A few interests control the majority share, with the democratic majority sharing the leftovers. + +What would the TABS capital share distribution be? + +Lets assume that, like most things, it won't be distributed evenly, and that "the rich get richer" is at least a working guideline for now. + +The next question in expectation becomes whether the rich in computational capital are _also_ those rich in currency capital. One line of reason suggests yes. After all, computational capital earns revenue in currency capital. And you need a lot of (generic) currency to pay for a lot of rigs in the first place. But miners have their costs, too. And the market for currency capital is independent from mining rigs, highly speculative already, and, compared to the mining rig market, highly liquid. + +Another variable we need to build context with is the share of miner-exclusive ("private") capital relative to network-available ("public") capital. If public capital dwarfs private currency capital, then the role of private capital diminishes against an assumed randomness inherent in the aggregated public balance. + +If the rich in mining capital are rich in currency capital, and the private/public capital share is _high_, then: + +`[TODO: add charts] ps This is not ideal. Rich (double rich) miners win more than they should. pss This already happens, I think, with plain PoW... but TABS would exaggerate it.` + +If the rich in mining capital are rich in currency capital, and the private/public capital share is _low_, then: + +`[TODO: add charts] ps This is better. Poorer miners are incentivized to buy representations of capital even if it only means reducing the advantage of the whales.` + +If the poor in mining capital are rich in currency capital... + +`[TODO: case matrix] ps These are not as 'interesting'. They are safer and less impactful and fairer. You can't win competitive blocks without hashrate. (As long as you can't compete with the public TABS value by yourself.)` + + + +### Hybrid Market Incentives + +Since a greater private TABS score will be advantageous _to some degree_, we expect a miner to be willing to buy (or hold) representations of capital. They might do this actively, by purchasing signed transactions from some venture, or they might do it passively, by discounting the gas price they charge for high-balance transactors. + +Beyond that, it starts to look like... economics, and I'd rather not fall any farther down that rabbit hole than I already am. + +It will be a free market experiment. ## Short-Term Finality Rate Increases From 10b64e38341e1e4ba4563b4636c223e363206841 Mon Sep 17 00:00:00 2001 From: ia Date: Tue, 31 May 2022 09:07:16 -0700 Subject: [PATCH 11/18] :hammer: Signed-off-by: ia --- _specs/ecip-tabs.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 6d88f7d04..5fcbd9bf4 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -4,7 +4,7 @@ title: A 2-Dimensional Consensus Arbitration Protocol, Difficulty * TABS author: Isaac (https://github.com/whilei) discussions-to: TODO status: Draft -type: Standards Track +type: Informational category: Core created: 2022-04-20 requires: EIP-100, ECIP-1105 @@ -224,9 +224,7 @@ If their balance _is sufficient_ to beat the TABS of the announced block, how do Since their expected TABS consensus score is differentially, at most, `+1/4096` of the proposed block, they can still achieve probabilistic equilibrium with the incumbent race given only `4095/4096` of the otherwise necessary hashrate (representing the likelihood of their PoW solution discovery). -So, unless the miner has `"51%" * 4095/4096` of the hashrate, the best strategy is still to ADOPT. - -This tells us that the "51%" rule is no longer "50% + epsilon". It becomes "49.9878% + epsilon". +So, unless the miner has `"50%" + epsilon * 4095/4096 = 49.9878% + epsilon` of the hashrate, the best strategy is still to ADOPT. ### A Deeper Dive into Block Distribution vs. Capital Distribution @@ -262,6 +260,18 @@ If the poor in mining capital are rich in currency capital... - if mining whales are capitalist pigs and the publicly represented capital is low, the game shifts significantly in favor of the rich (superlinear) - generally, we don't want anyone to have half or more of the public TABS value (because if that value is originally represented publicly, they could leave with it on their own fork and be competitive; same for difficulty) --> +### -- WIP + +The race, as a _race_, is preserved, and proof-of-work still rate limits block production. + +Miners, working independently, are expected to sometimes produce blocks at the same time. Well, close enough to the same time to be competitive. Let's call this near-simultaneous. + +For ETH and ETC I expect this rate to be around 10\%. A number of variables are at play, among them network latency and target block interval. + +I'll assume from here on out that the rate of symmetric block production is 10%. This is slightly higher than uncle rates at ETH and ETC. + + + ### Hybrid Market Incentives Since a greater private TABS score will be advantageous _to some degree_, we expect a miner to be willing to buy (or hold) representations of capital. They might do this actively, by purchasing signed transactions from some venture, or they might do it passively, by discounting the gas price they charge for high-balance transactors. From e95d0c8323d11efc9809686be773609ccf7985e5 Mon Sep 17 00:00:00 2001 From: ia Date: Tue, 31 May 2022 09:15:34 -0700 Subject: [PATCH 12/18] :floppy_disk: Signed-off-by: ia --- _specs/ecip-tabs.md | 48 ++++++++++++++++++++------------------------- 1 file changed, 21 insertions(+), 27 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 5fcbd9bf4..9a7e526a6 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -1,6 +1,6 @@ --- ecip: 110x -title: A 2-Dimensional Consensus Arbitration Protocol, Difficulty * TABS +title: 'TABS: An Experiment with a 2-Dimensional Consensus Scoring Protocol' author: Isaac (https://github.com/whilei) discussions-to: TODO status: Draft @@ -200,6 +200,9 @@ var attackChainConsensusScore_Hasher = (1.1*D) * (/*1.1/1=*/0.91*S) var attackChainConsensusScore_Richer = (0.91*D) * (1.1*S) ``` +![](https://i.imgur.com/MfPDxHQ.png) + + ## Conservative Adjustment Rate > An __adjustment denominator__ _r_ is defined as `4096`. @@ -212,6 +215,8 @@ For example, a block produced in the `[1-8] second` interval (`2049/2048*parent. Further investigation and analysis is encouraged for alternative adjustment rates, eg. `128`. +![](https://i.imgur.com/j5i4NAN.png) + ## PoW Race Incentives are (Mostly) Maintained The viability of a PoW-based network depends vitally on the competitiveness and fairness of the PoW race. Linearity (actually sublinearity) here is the goal; 1 GPU : 1 vote/gamble/point/token/whatever. @@ -240,17 +245,26 @@ The next question in expectation becomes whether the rich in computational capit Another variable we need to build context with is the share of miner-exclusive ("private") capital relative to network-available ("public") capital. If public capital dwarfs private currency capital, then the role of private capital diminishes against an assumed randomness inherent in the aggregated public balance. -If the rich in mining capital are rich in currency capital, and the private/public capital share is _high_, then: +Plots are provided below comparing views in this light for Ethereum and Ethereum Classic. + + + + +![](https://i.imgur.com/78qbNDw.png) -`[TODO: add charts] ps This is not ideal. Rich (double rich) miners win more than they should. pss This already happens, I think, with plain PoW... but TABS would exaggerate it.` +![](https://i.imgur.com/ulicnxG.png) -If the rich in mining capital are rich in currency capital, and the private/public capital share is _low_, then: + -`[TODO: add charts] ps This is better. Poorer miners are incentivized to buy representations of capital even if it only means reducing the advantage of the whales.` -If the poor in mining capital are rich in currency capital... -`[TODO: case matrix] ps These are not as 'interesting'. They are safer and less impactful and fairer. You can't win competitive blocks without hashrate. (As long as you can't compete with the public TABS value by yourself.)` + + + + + + -### -- WIP - -The race, as a _race_, is preserved, and proof-of-work still rate limits block production. - -Miners, working independently, are expected to sometimes produce blocks at the same time. Well, close enough to the same time to be competitive. Let's call this near-simultaneous. - -For ETH and ETC I expect this rate to be around 10\%. A number of variables are at play, among them network latency and target block interval. - -I'll assume from here on out that the rate of symmetric block production is 10%. This is slightly higher than uncle rates at ETH and ETC. - - - -### Hybrid Market Incentives - -Since a greater private TABS score will be advantageous _to some degree_, we expect a miner to be willing to buy (or hold) representations of capital. They might do this actively, by purchasing signed transactions from some venture, or they might do it passively, by discounting the gas price they charge for high-balance transactors. - -Beyond that, it starts to look like... economics, and I'd rather not fall any farther down that rabbit hole than I already am. - -It will be a free market experiment. - ## Short-Term Finality Rate Increases The rate of the network's production of orphan blocks (sometimes recorded as uncles) is expected to drop because the expected rate of objectively decidable (non-tie, "asymmetric") block competitions is expected to rise by around 50\%.[^4] The precise value of this expecation depends on the distribution of miner-available capital rates relative to the distribution of miner hashrates. From 09d7be397b5d8324f59e7166089686baaed3db43 Mon Sep 17 00:00:00 2001 From: ia Date: Tue, 31 May 2022 09:20:10 -0700 Subject: [PATCH 13/18] :eyeglasses: :pen: Signed-off-by: ia --- _specs/ecip-tabs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 9a7e526a6..41da2cad2 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -217,7 +217,7 @@ Further investigation and analysis is encouraged for alternative adjustment rate ![](https://i.imgur.com/j5i4NAN.png) -## PoW Race Incentives are (Mostly) Maintained +## PoW Race Incentives and Equilibrium The viability of a PoW-based network depends vitally on the competitiveness and fairness of the PoW race. Linearity (actually sublinearity) here is the goal; 1 GPU : 1 vote/gamble/point/token/whatever. From cc0affa558dba2a57388ea0e45208469d9a696d7 Mon Sep 17 00:00:00 2001 From: ia Date: Tue, 31 May 2022 09:22:13 -0700 Subject: [PATCH 14/18] :eyeglasses: :pen: Signed-off-by: ia --- _specs/ecip-tabs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 41da2cad2..932eda14f 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -193,7 +193,7 @@ var publicChainConsensusScore = (1*D) * (1*S) // An attacker with 110% hashrate of the "honest"/public net // needs 91% of the public TABS value to be competitive. -var attackChainConsensusScore_Hasher = (1.1*D) * (/*1.1/1=*/0.91*S) +var attackChainConsensusScore_Hasher = (1.1*D) * (/*1/1.1=*/0.91*S) // An attacker with 91% hashrate of the "honest"/public net // needs 110% of the public TABS value to be competitive. From 78fa4dd293c04741ed97a61142ddd2d11f8ef504 Mon Sep 17 00:00:00 2001 From: ia Date: Wed, 1 Jun 2022 09:21:31 -0700 Subject: [PATCH 15/18] :eyeglasses: :pen: Signed-off-by: ia --- _specs/ecip-tabs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 932eda14f..61c2032db 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -340,7 +340,7 @@ TAB and TABS value estimates can be derived retrospectively for Ethereum and Eth At the time of writing, and with limited sample sizes, I estimate TABS values as follows. - Ethereum's (ETH): ~500,000 ETH. -- Ethereum Classic's (ETC): ~7,000 ETC. +- Ethereum Classic's (ETC): ~5,000 ETC. Further efforts toward current or retrospective analysis of real-life PoW chains, not limited to ETC, is welcome. From d867b7d1ca88b2f727ba2eab7ea37fad52bd5465 Mon Sep 17 00:00:00 2001 From: ia Date: Thu, 2 Jun 2022 05:57:48 -0700 Subject: [PATCH 16/18] :floppy_disk: Signed-off-by: ia --- _specs/ecip-tabs.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-tabs.md index 61c2032db..0479f66e9 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-tabs.md @@ -247,14 +247,14 @@ Another variable we need to build context with is the share of miner-exclusive ( Plots are provided below comparing views in this light for Ethereum and Ethereum Classic. - - - ![](https://i.imgur.com/78qbNDw.png) ![](https://i.imgur.com/ulicnxG.png) + + + From dcd506b7e21ac30d65d2c857956220ba59b1a482 Mon Sep 17 00:00:00 2001 From: ronin Date: Wed, 13 Jul 2022 10:09:59 -0600 Subject: [PATCH 17/18] Assign ECIP Number + Assign Number + Add Discussion Thread --- _specs/{ecip-tabs.md => ecip-1108.md} | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) rename _specs/{ecip-tabs.md => ecip-1108.md} (99%) diff --git a/_specs/ecip-tabs.md b/_specs/ecip-1108.md similarity index 99% rename from _specs/ecip-tabs.md rename to _specs/ecip-1108.md index 0479f66e9..df4ad0889 100644 --- a/_specs/ecip-tabs.md +++ b/_specs/ecip-1108.md @@ -1,8 +1,8 @@ --- -ecip: 110x +ecip: 1108 title: 'TABS: An Experiment with a 2-Dimensional Consensus Scoring Protocol' author: Isaac (https://github.com/whilei) -discussions-to: TODO +discussions-to: https://github.com/ethereumclassic/ECIPs/issues/488 status: Draft type: Informational category: Core @@ -361,6 +361,3 @@ This strategy would be observable in real time by the public. An attacker could challenge the assumption that no entity controls more than the public TABS value for some time. The value of TABS relative to current supply and its account distribution informs this risk model. This attack, like a pure-PoW double-spend attack, would be invisible until published. - - - From 2ca5274953f999e5a3a332a154ff947f6ff71147 Mon Sep 17 00:00:00 2001 From: ronin Date: Wed, 13 Jul 2022 10:27:35 -0600 Subject: [PATCH 18/18] Update the Date Date was stale --- _specs/ecip-1108.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-1108.md b/_specs/ecip-1108.md index df4ad0889..9c4e2ec84 100644 --- a/_specs/ecip-1108.md +++ b/_specs/ecip-1108.md @@ -6,7 +6,7 @@ discussions-to: https://github.com/ethereumclassic/ECIPs/issues/488 status: Draft type: Informational category: Core -created: 2022-04-20 +created: 2022-06-02 requires: EIP-100, ECIP-1105 lang: en ---