Should ECAF be scaled? ECAF는 확장되어야합니까?

in #ecaf6 years ago

EOS new banner.png
(Summary from 12:00 November 12th till 12:00 November 13th)

WIDER RANGE OF SUMMARIES PUBLISHED DAILY ON: https://eosamsterdam.net/eos-telegram-summaries/

Arbitration & ECAF

User Tanish asks why we do not provide the custodian contract to dApps and users to stake theirs in custody of ECAF? That won't need any freeze and enforcement won't be based on the judgment of BPs and voters. User Martin responds and says the following: “Exactly. Eos is Turing complete. Of course it can be dapp layer. Why insist on base layer? Maybe like Luka was saying - it's because people aren't technical. That's the most generous interpretation! Dapp layer is a more flexible, more efficient solution that sacrifices nothing. Just a better design choice... And we don't have to argue!” User Eva says that it's an issue if one party is not cooperating or answering and likely is to run away with all money. ECAF likely would not freeze in those cases where the parties cooperate like this. And this is my point: it's first the parties to execute and BPs only in special situations. User Ben Gates from ECAF says that in fairness it seems clear to me that a hybrid system is required. User Ben Gates continues as follows: “As Eva said you will always need a base layer for some situations and as a fall back in others.”

User Tanish asks if ECAF is okay with dApps and BPs mentioning them in Ricardian contracts handling claims. User Sun Tzu replies as follows: “A principle of public dispute resolution forums is that they take any dispute that names the forum in a contract. A community forum like ECAF might just take EOS or EOS.IO claims, but it seems fairly clear that BPs and dApps are in the circle. Another question would be whether ECAF would happily take an ERC20 claim in Ethereum - unexpected, but if the shoe fits, why not?”

User Sharif asks why we are worried about scaling ECAF. The whole idea was that there should be multiple Arbitration Forums, each fit for purpose for specific use cases. Scaling ECAF was never the intention as far as Sharif is aware. User Tanish replies and says that when every arbitral ruling needs to be passed by ECAF and then BPs, that would definitely raise a lot of concern. User Tanish asks Sharif the following question: “Are you okay with enforcing thousands of claims and monitoring ECAF orders for sudden freezes? Do you think that could scale well?” User Sharif replies and says that there are two sides to this. With the right process and systems, it can scale. User Sharif then asks if it should scale and concludes that it should not. We need to constantly improve to essentially put ECAF out of work. They should only be necessary for the unforeseen edge cases. User Tanish asks what the right process is that comes to mind.

Other

User Sharif posted an article that you can read on Medium: https://medium.com/@eosdublin/stop-the-maddness-63e3c0eea66b

User Yvonne posts an article on the Constitution, you can read it here: https://medium.com/@eoslaomao/gov-if-the-rules-are-not-observed-what-is-the-meaning-of-the-constitution-60625f71eaae

User quantum replies to the article linked by Yvonne as follows: “‘The community needs to have trust in the BPs’ - false. The community must be able to verify BPs. Otherwise, the community doesn't matter. Every action by BPs must be reversible by voters.”
___________________________________________________________________________________________-

EOS 요약 포털 메인 페이지: https://eosamsterdam.net/ko/eos-telegram-summaries/

Arbitration & ECAF

Tanish는 ECAF에서 왜 dApp에게 수탁 계약을 제공 안 하고 사용자들에게 ECAF의 보관아래서 스테이킹을 허용하는지 묻습니다. 이것은 동결이 필요 없으며 블록생산자와 유권자의 판단에 기반하지 않을 것입니다. Martin은 다음과 같이 답변합니다: “EOS는 Turing을 완료했습니다. 물론 그것은 dApp 레이어가 될 수 있습니다. 기본 레이어를 고집하는 이유는 무엇입니까? Luka가 말한 것처럼 사람들이 기술적이지 않기 때문일 수 있습니다. 그것은 가장 관대한 해석입니다. dApp 레이어는 아무 것도 희생하지 않고, 유연하고 효율적인 솔루션입니다. 그냥 더 나은 디자인 선택입니다 ... 그리고 우리는 논쟁 할 필요가 없습니다!" Eva는 일방이 협력하거나 응답하지 않고 모든 돈을 가져가면 문제가된다고 말합니다. 당사자들이 이와 같이 협력하는 경우 ECAF는 계정 동결하지 않을 것입니다. 그리고 제 요점은 다음과 같습니다: 우선 당사자들이 먼저 실행을 하고 특별한 상황에서만 블록생산자이 하는 것입니다. ECAF의 Ben Gates는 공평하게 생각하면 하이브리드 시스템이 필요하다는 것이 분명합니다. Ben Gates는 다음과 같이 계속 말합니다: "Eva가 말했듯이 일부 상황에서는 기본 레이어가 필요할 것이고 다른 상황에서도 안전으로 기본 레이어가 필요할 것입니다."

Tanish는 ECAF가 dApps와 블록생산자들이 Ricardian에 ECAF를 언급하고 클레임을 처리하는 것에 대해 괜찮은지 묻습니다. Sun Tzu는 다음과 같이 회신합니다: "공개 분쟁 해결 포럼의 원칙은 계약에서 포럼의 선택하는 아무 분쟁을 해결하는 것입니다. ECAF와 같은 커뮤니티 포럼에서는 EOS 또는 EOS.IO 클레임만 받아들일 수 있지만 블록생산자 및 dApp가 특혜를 받는 것은 분명합니다. 또 다른 질문은 ECAF가 Ethereum의 ERC20 주장을 기쁘게 받아들일지의 여부입니다. 예기치 못했지만 신발이 맞으면 왜 안 되죠?"

Sharif는 왜 우리가 ECAF 스케일링에 대해 걱정하는지 묻습니다. 원래 아이디어는 여러 개의 중재 포럼이 있어야하며, 각 중재 포럼은 특정 사용 사례를 위한 것입니다. ECAF 스케일링은 Sharif가 알고 있는한 결코 의도 된 것이 아닙니다. Tanish는 ECAF와 블록생산자가 모든 중재 판결을 참여해야 할 때 많은 우려가 있을 것이라고 말했습니다. Tanish는 Sharif에게 다음과 같은 질문을합니다: "당신은 수천 건의 클레임을 실시하고 ECAF 동결 명령을 감시하는데 괜찮습니까? 그렇게 확장 할 수 있다고 생각하십니까?” Sharif는 두 가지면이 있다고 말합니다. 올바른 프로세스와 시스템을 통해 확장 할 수 있습니다. 그런 다음 Sharif는 확장되어야하는지 여부를 묻고, 그렇지 않아야한다고 결론을 맺습니다. 기본적으로 ECAF를 구식시키기 위해 근본적으로 끊임없이 개선해야합니다. ECAF는 예상치 못한 경우에만 필요합니다. Tanish는 올바른 프로세스가 무엇인지 묻습니다.