tezosプロトコルと過剰委任の問題
-
-
ここでの反対票について本当に興味があり、それらの理由が提供されたことを望みます.質問は本当に有効で便利です.答え自体が役立つかもしれません.「問題に答える」ための具体的な実装は主観的であり、批判の対象となります.わかります.Really curious about the downvotes here and wish the reasons for them were supplied. The question is really valid and useful. The answer itself could be useful. The specific implementation to 'answer the problem' is subjective and subject to criticism. I understand.
- 0
- 2019-04-10
- lostdorje
-
具体的な質問は何ですか?これを読んでいると、ディスカッションに招待されているような気がしますが、どうしたらいいのかわかりません.回答は、プロトコルの設計者が何を考えていたかを説明する引用または一次資料ですか?物事を現状のままに保つための、またはそれらを変えるための独立して考えられた動機?解決策または解散?漠然と関連した考えはありますか?What is the specific question? When I read this, I feel invited to join a discussion, but I am not sure what the answer should be. Is an answer a citation or primary source explaining what the designers of the protocol were thinking? Independently conceived motivations for keeping things the way they are ...or for changing them? Solutions or dissolutions? Any vaguely related thoughts?
- 0
- 2019-04-10
- Tom
-
けっこうだ.質問は少し言葉が多くて長いです、私は認めます.最初の文、最初の質問は主な質問です:なぜTezosプロトコルはパン屋の過剰委任を許可するのですか?@Ezyの答えは良い答えです.他にも理由があるのではないかと思います.過剰委任が設計上の選択である理由への引用またはリンクは、それらを知っていれば非常に優れています.Fair enough. The question is a bit wordy and long, I admit.The first sentence, the first question is the main question: Why does the Tezos protocol allow for baker over-delegation? @Ezy's answer is a good answer. I'm wondering if there are more reasons. Citations or links to why over-delegation is a design choice would be super if you know of them.
- 0
- 2019-04-11
- lostdorje
-
2 回答
- 投票
-
- 2019-04-11
プロトコルがオーバーデリゲーションを許可しなかった場合、パン屋が最大容量にある場合、暗黙のアドレスからxtzを削除することは許可されないことを意味します.ボンドが必要なのはパン屋が焼く権利を持っているときだけであり、そのときだけ彼女はそれらをポスト担保として投稿するために利用可能でなければならないので、これは受け入れられません.
パン屋が必要のないときに首都を移動できないようにすることは、パン屋の首都に対する虐待的な制約と見なされる可能性があり、パン屋のtz1アドレスを彼女に委任することで「ロックイン」できる攻撃ベクトルにつながる可能性さえあります.十分なxtz.全体として、これは個人がパン屋の営業を開始することを思いとどまらせるようなリスクになる可能性があります.
If the protocol did not allow for overdelegation it would mean that if the baker is at max capacity then she would not be allowed to remove any xtz from her implicit address. This is not acceptable because the only time that the bond is required is when the baker has a baking right and so only at that time she has to have to xtz available to post them as post collateral.
Preventing the baker from moving her capital when it is not required could be seen as an abusive constraint on baker’s capital and could even lead to an attack vector where one could “lock-in” a baker’s tz1 address by delegating to her just enough xtz. All in all this could become such a risk that deters individuals from starting bakeries operations.
-
ああ、ありがとう!優れた答えと多くの意味があります.これに関する文献へのポインタはありますか?これをもっとよく理解したいと思います.Ah, thank you! Excellent answer and make a lot of sense. Do you have any pointers to literature regarding this? I'd like to understand this better.
- 0
- 2019-04-11
- lostdorje
-
@lostdorje申し訳ありませんが、私はあなたの質問を読んでそれについて考えました:))@lostdorje no sorry i just thought abt it when reading your question :))
- 0
- 2019-04-11
- Ezy
-
- 2019-04-10
過度の委任の理由は、地方分権化を改善し、自己結合を促進することです.システムに「個人的な」利害関係がある.
多くの異なるチームがこれについて考え、解決策に取り組んでいます. CryptiumLabsによる
ブレブロの提案をご覧ください. ただし、それは単純なことではありません.
- 権限のないシステムであるため、AがBに委任するのを防ぐ必要がありますか?
- 委任者が誰であるかわからないため、委任者に連絡する方法はありません
- パン屋はその結合の全部または一部を取り除くかもしれません-これは許可されるべきではありませんか?
- パン屋がシャットダウンする可能性があります-これは許可されるべきではありませんか?
- セルフボンディングは、規模の経済と集中化を回避するための重要なメカニズムです
過剰な委任はパン屋にとって迷惑になる可能性がありますが、システムの分散化と利害関係を確保するための重要なメカニズムです.おそらく、この問題を「回避」するためのより良い方法は、より良いツールを作成し、アクティブな委任者とパン屋を奨励することです.
オーバーデリゲーションの詳細を読むことができます
ここ. The reason for over-delegation is to improve decentralization and encourage self-bonding; having a "personal" stake in the system.
Many different teams are thinking about this and working on solutions. Check out the Burebrot proposal by Cryptium Labs.
However it's not straigtforward;
- Being a permissionsless system, should we prevent A from delegating to B?
- There is no way to contact ones delegators since we do not know who they are
- A baker might remove all or part of it's bond - should this not be allowed?
- A baker might shut down - should this not be allowed?
- Self bonding is an important mechanism to avoid economies of scale and centralization
Over-delegation can be an annoyance for bakers, but it is an important mechanism to ensure decentralization and stake in the system. Perhaps a better way to "work around" this issue is to make better tools and encourage active delegators and bakers.
You can read more about overdelegation here.
-
あなたの考えとリンクをありがとう.代表団は、十分なXTZがない、または十分な技術的ノウハウがない人が、持ち株に「利息」を稼ぎ、インフレから保護され、間接的に投票に参加するのを助けることができます.過剰な委任を許可することが、単に委任を許可する以上に、これにどのように役立つかはわかりません.Burebrotは非常に興味深いものであり、それから何が生まれるのかを知りたいのですが、私が読んだことから、過度の委任を防ぐ提案には何も見当たりませんでした.Thanks for your thoughts and the link. Delegation can help those without enough XTZ or without enough tech know-how to earn 'interest' on their holdings and be protected against inflation and indirectly participate in voting. I don't see how allowing over-delegation helps any of this any more than just allowing delegation. Burebrot is very interesting and I would like to see what comes out of it, but from what I've read I did not see anything in the proposal that would prevent over-delegation.
- 2
- 2019-04-11
- lostdorje
Tezosプロトコルでパン屋の過剰委任が許可されるのはなぜですか?
ベーキングと承認のために提出する必要があるXTZの量をエンコードしたのは、Tezosプロトコル自体であり、プロトコルは、そのような資金を保持する必要がある期間も定義します.プロトコル自体が過剰な委任を防ぐメカニズムを提供しないのはなぜですか?
私が過度に委任されたパン屋であり、その事実を100pxのフォントで自分のウェブサイトに書き込むことができても、他の人が誤って私に委任する可能性があるのは残念なことのようです.
次のような操作をプロトコルに組み込むことはできませんでした:
tezos-client no longer accepting delegations for my_baker
?これにより、ベイカーアカウントにフラグが設定され、それ以降、このベイカーへの委任操作は失敗します.これは間違いなく何もないよりはましだと思われますが、パン屋側で手動の介入が必要です.
預金要件を実施するためにすでに構築されている独自のアルゴリズムを使用して過剰な委任を検出することにより、プロトコルがこれを自動的に防止することは、より厄介でおそらく不可能です.ただし、これは、委任が発生するのを待ってからそれに応じてアカウントを補充するのではなく、パン屋が過剰に委任されるのを防ぐために、アカウントにXTZを時期尚早に入力する必要があることを意味するため、注意が必要です.
>誰かがこれについて考えている、または取り組んでいるのだろうか?重大な問題のようです.
(この質問は主観的な領域に少し向きを変え始めていることに気づきましたが、それでも非常に重要な質問だと感じており、どこにも質問や回答が見られませんでした.この質問はどこかに存在するはずです.非常に公開されて目に見えるフォーラムなので、ここで質問します.)