Block Producer Agreement Discussion Thread

Here's the text just published by @thomasbcox:

As a Block Producer (BP), I/we promise to:

  1. Produce exactly the authorized number of blocks faithfully, accurately, at the appointed time in the rotation
  2. Never produce and sign two or more blocks with the same block height or block interval
  3. Never censor governance related transactions such as votes or Arbitration related transactions
  4. Only add "good" transactions from the transaction pool to the block
  5. Make a good faith effort to include as many "good" transactions as possible to the block without undue discrimination
  6. Exclude "bad" transactions from the block, and publish why they were excluded
  7. Show no favoritism among transactions, ordering them in a FIFO fashion or using some other ordering mechanism that is declared publicly in advance, including the default ordering provided by the unmodified software
  8. Refrain from using my/our superior information to "front run" transactions nor enabling anyone else to “front run”
  9. Accept as valid any Arbitrator’s order that’s
    i. signed by an Arbitrator
    ii. that the chain shows was assigned to a Case,
    iii. such that the order affects only the Accounts named in that Case, and
    iv. the Arbitrator is in good standing with their Arbitration Forum, and
    v. the original Transaction that gave rise to the Case names that Arbitration Forum as the venue for dispute resolution
  10. Only freeze accounts when authorized to do so by a valid Arbitrator’s order
  11. Always file a dispute against myself/ourselves after taking initiative to act on an emergency
  12. Provide at least four (4) public endpoints running full nodes (the Minimum Configuration)
  13. Not requesting my/our daily Vote Bonus pay on days when I/we don’t have the Minimum Configuration running, and repaying any Vote Bonus income collected while the Minimum Configuration wasn’t running
  14. Disclosing all ownership of my/our organization greater than 10%
  15. Not sharing more than 10% ownership with another BP

https://github.com/EOSIO/eos/blob/thomasbcox-patch-2/governance/bp_agreement.md

Comments

  • joshkauffmanjoshkauffman Posts: 20 Jr. Member - 1/5 EOS Tokens
    edited May 14

    I'm trying to read this thru the eyes of a token holder who doesn't know very much about the details.

    --4. what is the definition of "good" transactions? (could even just add an asterix and define below)
    --5. same as 4
    --6. define "bad"
    --7. can different BPs choose different mechanisms? Or a single mechanism should be agreed upon?
    --9. iv. Shouldn't it be up to the Arb Forums to ensure that an Arb is in good standing before they can be assigned to a case? Why should BPs have to ensure they are in good standing?
    --10. if (for example) i see that my account is acting oddly, would there be a free and quick method to freeze my account to avoid further issues? Let's say I have 10 EOS in my account, and it costs 50 to create an arb order, will i have no ability to free the issue?
    --15. if the point of this was to say that a single entity cannot own more than %10 of two BPs, it doesn't read that way to me. Reads more like I cannot swap 10% of my business entity with another BP.

    Representative from EOS Canada
    All opinions my own unless stated otherwise

  • mikemike Posts: 27 admin
    edited May 14

    Minimum Configuration might be a bit high to begin with, I would be keen to keep it lower to allow as many new entrants as possible

  • Hahn_eosnodeoneHahn_eosnodeone Posts: 1 Brand New

    4-6. Same question as Joshua's.
    9. What are the examples of arbitrator's order where BPs wouldn't want to accept?
    14. Disclosing ownership of a BP comes to me as intended to clarify if there's any conflict of interest. There's many BP candidates who's either a subsidiary of an existing company or a part/dept of an existing company. How do we define conflict of interest? There's very fuzzy line between what'sok and what's not.

  • RomanCryptoLionsRomanCryptoLions Posts: 41 Jr. Member - 1/5 EOS Tokens
    edited May 14

    2. Never produce and sign two or more blocks with the same block height or block interval.

    I'm fairly certain this does not make sense. It needs to be rephrased carefully.

    In his argument for DPOS 3.0, Dan Larimer described how DPOS 2.0 allowed for block producers, even acting in good faith, to encounter situations in which they have to sign conflicting blocks. It seems to me that the conflicting blocks can easily happen at the same height, so forbidding the signing of blocks with the same height does not work.

    The DPOS 3.0 solution is to simply acknowledge the earlier signature when you do the later one.

    I summarized it here https://steemit.com/dpos/@cryptolions/a-summary-of-dpos-1-0-2-0-and-3-0#comments

    and link to Dan's description in Github comments too.

    4. Only add "good" transactions from the transaction pool to the block

    Suggest replacing "good" with "non-fraudulent".

    6. Exclude "bad" transactions from the block, and publish why they were excluded

    Suggest replacing "bad" with "fraudulent".

    9. Accept as valid any Arbitrator’s order that’s...

    Suggest adding the word "lawful": "any Arbitrator's lawful order."

    This is analogous to how soldiers in the US take an oath to the Constitution that supercedes their loyalty to the President or to their commanding officers.

    10. Only freeze accounts when authorized to do so by a valid Arbitrator’s order

    Suggest the phrase "valid and lawful".

  • RomanCryptoLionsRomanCryptoLions Posts: 41 Jr. Member - 1/5 EOS Tokens
    edited May 14

    Regarding 2. Never produce and sign two or more blocks with the same block height or block interval.

    There's a better way to phrase it.

    The answer lies in these comments by Dan regarding DPOS 3.0: https://github.com/EOSIO/eos/issues/2718

    Suppose a network with producers A, B, and C has an issue that causes two block producers to lose communication for a short period of time such that producer A produces block N at time T and producer B produces block N at time T+1. Now suppose producer C breaks the tie by building block N+1 at time T+2 on top of B’s block N with time T+1. After this happens and A learns of C’s block N+1, A will switch to the longer fork. Next time A produces a block he will indirectly confirm B’s block N which conflicts with A’s previously produced block N.

    Under the DPOS 2.0 rules, A’s block N would have votes from A, B, and C and therefore become irreversible due to (2/3+1) confirmation. Under DPOS 3.0 we require A to disclose that he previously confirmed an alternative block N. Due to this disclosure the network will not count A’s block as having voted for B’s block N. This leaves B’s block N with only 2 votes which is not enough to achieve irreversibility.

    Under DPOS 3.0 B’s block N will never achieve direct irreversibility because it requires votes from A, B, and C to have 2/3+1 and A cast a vote on an alternative block N. Instead, block N+1 will become irreversible once A producers N+2 and B produces N+3. This would give block N+1 the 3 votes necessary to reach 2/3+1. Once C’s block N+1 is irreversible, B’s block N is deemed irreversible as well.

    To implement this algorithm each block producer includes the highest block number (H) they have previously confirmed on any fork in the block header. When block N is applied only blocks in the range [H+1, N] receive votes toward irreversibility.

    Any producer who signs a block with an overlapping range is deemed byzantine and will generate cryptographic proof of misbehavior.

    . . . .

    Under this these rules there are now two ways for producers to sign byzantine statements:

    1. Sign two blocks with the same block number directly or indirectly
    2. Sign two blocks with the same block time

    The comment concludes with

    The solution to this problem was discovered collaboratively by Bart, Arhag, and myself along with some other members of the B1 team.

    I would check with one of those guys about the precise wording for #2.

  • thomasbcoxthomasbcox Posts: 145 Sr. Member - 1/5 EOS Tokens

    Good discussion. Let's please keep this active and I'll try to synthesize the input once folks have all had a chance to weigh in.

    If this was helpful, please UPVOTE. If not, please REPLY so I can improve.

    Thomas Cox
    blockchain governance expert - active in the EOSIO ecosystem
    US: +1 503.516.3886

    (all opinions are my own)

  • thomasbcoxthomasbcox Posts: 145 Sr. Member - 1/5 EOS Tokens

    @mike said:
    Minimum Configuration might be a bit high to begin with, I would be keen to keep it lower to allow as many new entrants as possible

    I got some pushback on this in Telegram also.

    I'm wondering if we should instead have each BP Candidate publish their 'bid' (how?) of how many servers / endpoints / whatever it is they will run, if voted in as a Standby. Then they are offering a contract. If they were to take payment without running the configuration they themselves promised, they're committing fraud. (Some form of inspection or verification is needed here.) And the voters can look at the bids and decide what to vote for.

    I'm even wondering if it might not make sense to bid "I will host 1 endpoint for every X% of the vote I get" or some other sliding scale that would be deterministic and fair all around. This is at the outer edges of my technical skill set, however.

    Thoughts?

    If this was helpful, please UPVOTE. If not, please REPLY so I can improve.

    Thomas Cox
    blockchain governance expert - active in the EOSIO ecosystem
    US: +1 503.516.3886

    (all opinions are my own)

  • Sam_SapoznickSam_Sapoznick Posts: 68 Member - 2/5 EOS Tokens
    edited May 15

    4, 5, 6 -- Echoing same remarks as others have made: seek better definition of "good" and "bad". Perhaps with enumeration of examples if it's not possible to better-define in generalized description.

    9 - possibly add: such that.. "...the order came from an Arbitration Forum duly authorized by token holders according to the EOS RDR." (Avoids confusion if someone sets up "Joe's Arbitration Service" and submits arb orders which otherwise appear valid -- but token holders never authorized "Joe's Arb Service" to perform arbitration.)

    11- "Always file a dispute against myself/ourselves after taking initiative to act on an emergency".

    This language isn't clear to me. Suggest something more along the lines of, "Always file a timely dispute pursuant to any unilateral emergency action I/we may take. (Any action which would otherwise require a valid Arbitrator's order, but executed without such an order due to emergency.)

  • pythagoras345pythagoras345 Posts: 5 Brand New
    edited May 15

    I was one that gave some push back on telegram to the minimum config. But I now realized I misunderstood. I was stating who cares how many “producing” servers we have if we don’t miss block production. But I now realize, this requirement was not regarding producing nodes, but full nodes to give dapp access. In this regard, it does seem legit to require each bp to provide a certain level of full nodes. Thus, I like Thomas’s idea of a sliding scale based on bp’s vote total. It could also be sliding scale based on number of dapp users. Like only two servers are needed until we have 10m users, 4 between 10-100 million users, 8 between 100-500m users, and so on.

  • TheAwakenmentTheAwakenment Posts: 7 Brand New

    4-6. Agree with most - Needs clear definitions.
    14-15. I think this needs more thought. If I understand it correctly, the following scenario would be perfectly OK..
    10 whales get together and each take a 10% stake in x10 BPCs. They then use their large holdings to collectively vote in these BPs.
    10 Whales now collectively own 10 BPs ?
    If correct, this 10% limit needs to be lowered to something like 1%.

  • TheAwakenmentTheAwakenment Posts: 7 Brand New

    Do people think we should also address BPs voting for other BPs in this document?
    Conversations with Sun Tzu on Telegram suggests BPs voting for other BPs may be viewed as 'wrong' at some point in the future (not independent). BPs would therefore be putting themselves at risk if they chose to vote for another BP.
    If this point were raised in this document, then at least we would have something to refer to in an arbitration case (if a non-independence charged was filed against a BP in the future). I therefore think it worth discussing here - Should BPs be allowed to vote for other BPs?

  • maomao Posts: 23 Jr. Member - 1/5 EOS Tokens

    What does 15. Not sharing more than 10% ownership with another BP? Meaning block A and block B can not be invested by the same ultimate investor for more than 10% each? If that's the case, it should be included in voting article saying that any voter should not have big influence over more than one BPs.

    I suggest to add:

    a. Disclose BP’s real entity name and core team member’s real name and place(s) domiciled and accept consequences which includes being “walled” for certain time, account frozen, being kicked out from EOSIO when acting bad and ruled by the Arbitrator.
    b. Disclose shareholders and token holders (if with a token) who own > 10%
    c. Disclose related parties and related parties transactions
    d. Do not manipulate/involve in manipulating votes (which include vote buying)

    @thomasbcox

    -EOSREAL
    A New World of EOS
    MP/VM: +1-949.468.5388

  • EOSNewYorkEOSNewYork Posts: 18 Jr. Member - 1/5 EOS Tokens

    Re: #12, JEM suggested the following in Telegram in place of the current #12:

    "Maximum avg response time to API requests should be less than xxx, excluding network latency."

    The 'xxx' should be informed by the community.

    EOS New York

  • maomao Posts: 23 Jr. Member - 1/5 EOS Tokens

    EOSREAL further propose the following version of BP agreement for everyone's reference:

    EOS Block Producer Agreement

    This EOS BLOCK PRODUCER AGREEMENT (the "Agreement"), when signed by the block producer (BP), constitutes a binding agreement of BP.
    1. BP agrees to abide by the EOS Constitution.
    2. BP agrees to disclose the official name, working email, date of birth of the ultimate beneficiary owners with over 10% shares in the organization and its related parties. This information shall be posted on BP website, and EOS GO Forum, and updated in 48 hours if there is a change.
    3. BP agrees to disclose the official name, working email, of the main operation management team members. This information shall be posted on BP website, and EOS GO Forum, and updated in 48 hours if there is a change.
    4. BP agrees to meet the minimum hardware requirement, and provide the continuing solid, smooth service for EOS system.
    5. BP agrees to provide the quarterly audited hardware configuration reports if BP has been elected more than 10 days in continuous 90 days within 15 days of each quarter end; the auditor list will be provided by BLOCK.ONE and BP chooses one from the list. This report shall be posted on BP own website, and EOS GO Forum in 48 hours once the report is ready.
    6. BP agrees to provide the semiannual audited income statement and balance sheet, related party transactions within 30 days of June 30 and Dec 31 if BP has been elected more than 75 days in continuous 180 days; the auditor list will be chosen by BLOCK.ONE and BP chooses one from the list. This report shall be posted on BP own website, and on EOS GO Forum in 48 hours once the report is ready.
    7. BP agrees to produce exactly the authorized number of blocks faithfully, accurately, at the appointed time in the rotation.
    8. BP agrees it never produces and signs two or more blocks with the same block height or block interval.
    9. BP agrees it never censors governance related transactions such as votes or Arbitration related transactions.
    10. BP agrees to work diligently, honestly to only add "beneficial to EOS system" transactions from the transaction pool to the block.
    11. BP agrees to make a good faith effort to include as many "beneficial to EOS system" transactions as possible to the block without undue discrimination.
    12. BP agrees to exclude "malicious to EOS system" transactions from the block, and publish in EOS GO forum why they were excluded.
    13. BP agrees to show no favor among transactions, ordering them in a FIFO (First In First Out) mechanism.
    14. BP agrees to refrain from using the foreknowledge to "front run" transactions nor enabling anyone else to “front run”.
    15. BP agrees to enforce the lawful order from any Arbitrator.
    16. BP is entitled to pro-rata receive the annual 1% inflation of total EOS tokens based on his eligible time as BP.
    17. BP agrees to maintain full financial independence at all times, and will not look for controlling over 10% of other BP or allow other BP/its ultimate beneficiary owner controlling over 10% of its own stakes.
    18. BP agrees to renounce its BP position immediately when the local law enforcement authority asks it to act against the EOS constitution, and shall notify EOS community by posting the renunciation statement on its own website and EOS GO Forum immediately. BP can apply for relevant compensation for incurred expense to the arbitrator, and arbitrator will finally decide the exact compensation.
    Sanctioning, Fining and Removing BPs
    19. BP can only be sanctioned, fined, removed by the Arbitrator.
    20. Only if BP’s action shows malice towards the EOS system, another member of EOS community, the Arbitrator can give order to sanction, fine, and remove it.
    Such actions include, but not limited to:
    a. Byzantine behavior
    b. Ignoring the transaction of a specific party without permission
    c. Freezing an account without Arbitrator’s order
    d. Freezing a contract without Arbitrator’s order
    e. Overwriting code without Arbitrator’s order
    f. Intentionally sabotaging EOS system
    g. Refusing to enforce the Arbitrator’s order

    @thomasbcox

    -EOSREAL
    A New World of EOS
    MP/VM: +1-949.468.5388

  • cypherglasscypherglass Posts: 3 Brand New

    We are strongly against #15. We believe it should be replaced with "15. No Block Producer shall have any interest in any other Block Producer. All Block Producers will be completely transparent about all owners and beneficiaries of their Block Producer, regardless of their ownership size.”

    It's incredibly important that all Block Producers be completely independent from all other Block Producers in order to prevent corruption and collusion.

  • freiheitfreiheit Posts: 4 Brand New

    I agree on preventing also 10% ownership exchange beetween BPs, while I am not sure that the 100% transparency is the best option for the potential risk of attacks vs BPs.

  • JetseSprey_EOSIOAmsJetseSprey_EOSIOAms Posts: 22 Jr. Member - 1/5 EOS Tokens
    edited May 19

    EOS Amsterdam developed a code of conduct (that also incorporates some of the elements of the agreement detailed this discussion (link below)).

    Since without further arrangements no one can really enforce that we live by our code of conduct, we have introduced transparent and public complaint proceedings. Anyone who feels we don't live by our rules can launch these proceedings. And it will be out in the open. We have chosen full transparency as a means to keep us compliant.

    With the BP agreement the arbitration could be used to secure compliance. Just like the Constitution shall be enforced. The BP agreement then becomes part of the Constitution. As a more specific rule on how to behave.

    Would this be how the agreement will work? Or will we introduce specific proceedings?

    https://steemit.com/eos/@eosamsterdam/eos-amsterdam-code-of-conduct

    Jetse Sprey
    EOS Amsterdam
    eosamsterdam.net

  • cypherglasscypherglass Posts: 3 Brand New

    To be clear, we are still STRONGLY against #15. This needs to be changed to prevent Block Producer cartels wherein a group of BPs are financially incentivized to keep each other in power against the wishes of the community.

  • Jan_Smit_EOS_NLJan_Smit_EOS_NL Posts: 4 Brand New
    edited May 27

    DutchEOS fully agrees re #15 that "No person or entity shall own any stake in more than one BP." Moreover we should consider making this part of the constitution (not just the BP Agreement). We may want to prevent that any EOS developer, block producer or investor owns any stake in more than one BP.

  • muralimurali Posts: 6 Brand New

    One other option is to modify the 15 as follows:

    No person or group of related persons shall own or control more than 10% of 2 or more BPs.

    Related persons is defined as related individuals (including by common directorships/governance positions in entities), related corporate entities having more than 10% common ownership or 10% of common directors or governing persons or entities which are accustomed to acting in response to instructions from a common owner or controller.

    This will get around the fact that we may some investors having relationship with multiple BPs but together they cannot control how the BPs act.

  • hackerhacker Posts: 6 Brand New

    against 15 in its present form. bp investors need lucrative but well defined exit strategies or eos will risk bp cartel centralization

  • sflowers17sflowers17 Posts: 16 Brand New
    edited May 31

    @TheAwakenment said:
    Do people think we should also address BPs voting for other BPs in this document?
    Conversations with Sun Tzu on Telegram suggests BPs voting for other BPs may be viewed as 'wrong' at some point in the future (not independent). BPs would therefore be putting themselves at risk if they chose to vote for another BP.
    If this point were raised in this document, then at least we would have something to refer to in an arbitration case (if a non-independence charged was filed against a BP in the future). I therefore think it worth discussing here - Should BPs be allowed to vote for other BPs?

    I have the same question regarding BPs voting for other BPs. I'm HEAVILY leaning toward NO is the correct answer for 2 main reasons. The first should be obvious, the block producers are the first ones to touch the newly minted EOS through inflation and performing their duties and therefore automatically have the ability to sustain power by voting for each other with the added weight of these new tokens. Second, BPs should answer to 2 equal parties in my opinion, the dApps and the token holders (voters) period. If they would like to remain in power, keep those 2 groups happy, simple. Thoughts @cypherglass?

  • MortenMorten Posts: 27 Jr. Member - 1/5 EOS Tokens

    @sflowers17 said:

    @TheAwakenment said:
    Do people think we should also address BPs voting for other BPs in this document?
    Conversations with Sun Tzu on Telegram suggests BPs voting for other BPs may be viewed as 'wrong' at some point in the future (not independent). BPs would therefore be putting themselves at risk if they chose to vote for another BP.
    If this point were raised in this document, then at least we would have something to refer to in an arbitration case (if a non-independence charged was filed against a BP in the future). I therefore think it worth discussing here - Should BPs be allowed to vote for other BPs?

    I have the same question regarding BPs voting for other BPs. I'm HEAVILY leaning toward NO is the correct answer for 2 main reasons. The first should be obvious, the block producers are the first ones to touch the newly minted EOS through inflation and performing their duties and therefore automatically have the ability to sustain power by voting for each other with the added weight of these new tokens. Second, BPs should answer to 2 equal parties in my opinion, the dApps and the token holders (voters) period. If they would like to remain in power, keep those 2 groups happy, simple. Thoughts @cypherglass?

    My current opinion is that BPs are token holders to.

    They provide a valuable service to the chain and are rewarded with tokens for this effort. Unless there are strong arguments against it, BPs should be able to utilize their tokens in any way they want, including voting for themselves, other BPs or worker proposals.

    If BPs aren't able to utilize their token rights they are incentivized to dump them on the market causing a price drop. On the other hand, if someone buys a lot of tokens to vote for themselves they are in effect doing the community a favor by increasing the token price.

    BPs will know a lot about other BPs technical skills and EOS in general. They will probably be some of the most well informed voters.

    As long as BPs are transparent about their practices, the other token holders can vote on what BP behavior they find appropriate. Someone might be okay with a BP voting for another BP while others may not. Different opinions will result in different votes and the majority decides.

    I'd love to hear other opinions on this.

  • sflowers17sflowers17 Posts: 16 Brand New

    @Morten I guess my point boils down to the power dynamics of this governance system. Normally I would agree that yes, BPs should enjoy all the same rights in regards to using their EOS tokens as they see fit, but this underestimates the power dynamic of said tokens and does not properly account for the full context of circumstances. Furthermore, simply saying and if the community doesn't like what the BPs are doing they can just vote them out completely misses my point. HOW? HOW can you vote them out when they've become corrupted and no longer seem to listen or care about the concerns of the community and those voting if they simply hold the majority of this power amongst themselves? BPs are ALREADY receiving their rewards and rightly so by the work they do, allowing and GIVING them the power to vote and thereby consolidate their own power is unnecessary and unwise in my opinion. This is essentially not much different than the system we already have. Where BPs fear the token holders there is liberty, where the token holders fear the BPs there is tyranny or something like that.

Sign In or Register to comment.