(Summary from 12:00 October 11th till 12:00 October 12th)
HELLO ALL! WE WILL ALSO PUBLISH OUR SUMMARIES ON: https://eosamsterdam.net/eos-telegram-summaries/ SO GO GIVE IT A VISIT!
Referendum
User Sun Tzu replies to user HMarkov: ‘Being in the core code or not, the result is just a packet that says ‘upgrade to this code. YES, 60%’ which is not exactly a contract that can execute the upgrade. I don’t think we’re at the point to doing automatic upgrades through referenda. In practice, the BPs will likely approve the update manually.’ User Samupaha: ‘Automated upgrades based on referendum would be pretty cool. But I guess first we should put the source code onchain?’ User Todor asks how you automatically force block producers to upgrade the software they’re running? That’s one layer below the base blockchain layer. User Kevin Rose: ‘You don’t. We all test all updates and deploy systematically across nodes.’ User Todor: ‘Yeah, that was my point. We need to have infrastructure at the bottom, and this includes the software that’s being run by nodes. This is the thing that enables automation on the blockchain level.’ User nutela states that instead of automating, each BP should evaluate if the newest version should be indeed the best. He thinks it’s up to the voters to see if they support a new version or not by electing/voting on BPs. It’s like a service. It would be even better if some BPs keep the older version in case something breaks down.
User Samupaha replies to Todor: ‘I was thinking more of a situation where the official repository is on the blockchain. We would have some kind of mechanism to decide who can make changes to it. Some changes would require passing a referendum, and those could be automated: the new code is inserted to the repo when the referendum is over’. User Todor says that automated repo updating can be implemented, but I think we are far from reaching the point where we won’t need manual repo management.
User Kevin Rose: ‘Does anyone know of any written posts that attempt to define what’s referendum and what’s BP purview?’ User Syed: ‘The constitution says that anything that changes the main doc and it’s children would require a referendum.’ User Branden Espinoza thinks BPs should not be commoditized. They should be different, some should make risky moves while others should pharisaically adhere to hedged rules. He doesn’t think there should be a clear line between what a BP can do and what it can’t do.
User Thomas Cox replies to Kevin Rose: ‘If the new code does not involve a change of the Ricardian contracts, and no user experience changes, and no policy changes, then it’s BP discretion. IMHO.’
Voting
User Samupaha’s take on voting is: How we can incentivize people to think more how they vote. I would give more voting power to those who stake their tokens for a longer time. They have more skin in the game, so they need to think more of their voting. User Tanish: ‘+1, dApplications have incentive to vote for good BPs and keep running their business.’ User Samupaha says that can also be a problem, if it goes too far. Apps will vote for BPs who support their business model and repress others. User Tanish: ‘So, stake and time-based voting could work. I think you mentioned this somewhere.’ User Samupaha: ‘Here is my old proposal: https://forums.eosgo.io/discussion/538/core-token-lockup-time .‘ User Nutela: ‘Wow, excellent idea, really like your proposal of giving extra voting power if you lock your funds for a longer period. That might be even better than disincentivizing voting on the same people all the time with respect to stake you have.’
User Thomas Cox suggests that instead of disincentivizing voting for the same people, one could create a strong identity system for BPs and implement term limits or a ‘fallow period’ during which an active BP would need to be no more than standby for a while, thus mixing things up. Combine that with ACTUALLY enforcing the terms of the Regproducer contract and perhaps upgrading the terms of Regproducer to require revealing revenue sharing agreements, and we might be on a good path.
Later he shares the following video while saying that to ‘incentivize’ is not the only way: 
User Todor: ‘I have been thinking of a progressive voting weight scheme - the more you vote, the higher the weight of your subsequent votes. Generally the idea is that not everyone cares about governance. Decisions should be made by people who care. Experience is a big factor - it takes a while to learn to make good decisions. So, by voting you show you are committed to governance and that you have gained experience doing so. Therefore, your next vote should matter just a bit more.’ User JP says it seems that this would compound/reinforce the stake weighted system we already have. User Todor: ‘One of the reasons I mentioned that a lot of constraints are needed to make this work. Like upper/lower limits for weight modification coefficient; decay; weight modification based on amount of stake; WIP.’
Other
User Samupaha: https://www.coindesk.com/nearly-1-billion-stolen-in-crypto-hacks-so-far-this-year-research/
User Jun shares EOS Governance Study Group #6: 
User Crispy: https://technosphere-magazine.hkw.de/p/The-Byzantine-Generalization-Problem-8UNNcM8VShTpBGWRuob1GP
안녕하세요! 저희 웹사이트의 새로운 포털에도 매일 요약 올라갑니다. 'EOSIO Gov' 와 'EOS 관련 게시물' 카테고리에서는 항상 한국어로 변역된 버전이 같이 올라가니까 기대해주시고 방문해주세요!
포털 메인 페이지: https://eosamsterdam.net/ko/eos-telegram-summaries/
Referendum
Sun Tzu는 HMarkov에게 다음과 같이 답합니다: '핵심 코드에 속하는지 여부에 관계없이 결과는 ‘이 코드로 업그레이드하라는 패킷입니다. 이것은 업그레이드를 실행할 수있는 계약이 아닙니다. 나는 우리가 투표를 통해 자동 업그레이드를 할 시점에 있다고 생각하지 않습니다. 실제로, BP는 수동으로 업데이트를 승인 할 가능성이 높습니다.' Samupaha: 투표를 기반으로하는 자동 업그레이드는 매우 좋을것 같습니다. 하지만 우리는 먼저 소스 코드를 on-chain에 묶어야한다고 생각합니다.' Todor는 BP가 실행중인 소프트웨어를 자동으로 업그레이드하도록 어떻게 하는지 묻습니다. 이것은 기본 블록 체인 레이어 하나 아래의 레이어입니다. Kevin Rose: '그렇지 않습니다. 우리는 모두 모든 업데이트를 테스트하고 노드를 통해 체계적으로 배포합니다.' Todor : '네, 그게 내 포인트입니다. 맨 아래에 인프라가 있어야하며 여기에는 노드에서 실행되는 소프트웨어가 포함됩니다. 이것은 블록체인 레벨에서 자동화를 가능하게하는 것입니다.' nutela는 자동화하는 대신 각 BP가 가장 최신 버전이 실제로 최상인지 평가해야한다고 말합니다. 그는 유권자가 BP를 선출하거나 투표함으로써 새로운 버전을 지원하는지 여부를 확인할 수 있다고 생각합니다. 그것은 서비스와 같습니다. 무언가가 무너질 경우를 대비하여 일부 BP가 이전 버전을 유지하는 것이 더 낫습니다.
Samupaha는 Todor에게 다음과 같이 회신합니다. "나는 공식 저장소가 블록체인에있는 상황을 더 생각하고있었습니다. 이 경우 우리는 누가 그것을 변경할 수 있는지 결정하는 메커니즘을 가질 것 입니다. 일부 변경은 일단 투표를 통과해야하며, 자동 투표가 가능합니다. 투표가 끝나면 새로운 코드가 저장소(repo)에 삽입됩니다. Todor는 자동 저장소 업데이트를 구현할 수 있다고 말하지만 수동 저장소 관리가 필요하지 않은 시점에 이르기에 멀었다고 생각합니다.
Kevin Rose: 투표와 BP의 범위가 무엇인지 밝히기 위해 쓰여진 게시물이 있습니까?" Syed: 주 헌법 개정안과 그 자녀들을 바꾸는 것은 투표를 요구할 것이라고 헌법에 명시되어 있습니다." Branden Espinoza는 BP가 상품화되어서는 안된다고 말합니다. 그들은 달라야하며, 위험한 움직임을 만들어야하는 BP도 있고 규칙을 준수해야하는 BP도 있습니다. 그는 BP가 할 수 있는 일과 할 수 없는 일 사이에 명확한 경계가 있어야한다고 생각하지 않습니다.
Thomas Cox가 Kevin Rose에게 다음과 같이 답합니다. '새 코드에 Ricardian 계약이 변경되지 않고, 사용자 경험이 변경되지 않고, 정책이 변경되지 않으면 BP 재량입니다. 저의 솔직한 의견으로는.'
Voting
Samupaha의 투표권은 다음과 같습니다: 사람들이 투표 방법에 대해 더 많이 생각해보도록 어떻게 유도 할 수 있을까요?. 나는 더 긴 시간 동안 토큰을 스테이크 하는 사람들에게 더 많은 투표권을 줄 것입니다. 그들은 게임에서 더 많은 위험을 감수하므로 투표를 대해 더 생각해야합니다. Tanish: '+1, dApplications는 좋은 BP에 투표하고 사업을 계속 운영 할 동기가 있습니다.' Samupaha는 너무 멀리 지나치면 문제가 될 수 있다고 말합니다. Apps는 그들의 비즈니스 모델을 지원하고 다른 사람들을 억압하는 BP에게 투표 할 것입니다. Tanish: '그래서, 스테이크 및 시간 기반 투표는 가능 할 수 있습니다. 나는 당신이 이것을 어딘가에서 언급했다고 생각합니다.' Samupaha: '이것이 저의 옛 제안입니다 : https://forums.eosgo.io/discussion/538/core-token-lockup-time 'Nutela : '훌륭한 생각입니다, 더 긴 기간 동안 자금을 잠그면 추가 투표권을 주는 제안을 정말 좋아합니다. 그것은 당신이 가지고있는 스테이크와 관련하여 항상 동일한 사람들에 대한 투표를 폄하하는 것보다 훨씬 낫습니다.'
Thomas Cox는 동일한 사람들에 대한 투표를 불식시키지 않고 BP에 대한 강력한 신원 체계를 구축하고 기간 제한 또는 '휴면 기간'을 구현할 수 있으며, 이 기간 동안 활동중인 BP는 잠시 동안 대기 상태에 머물러 있어야하는 프로세스를 제안합니다. Regproducer 계약의 조건을 실제로 시행하고 Regproducer의 조건을 업그레이드하여 매출 공유 계약을 밝혀야하는 경우 좋은 길을 걷게 될 것입니다.
나중에 '인센티브'가 유일한 방법이 아니라고 말하면서 다음 동영상을 공유합니다.
Todor: '나는 진보적인 투표 체력 계획을 생각해 왔습니다. 투표를 많이할수록 후속 투표의 가중치가 높아집니다. 일반적으로 모두가 거버넌스에 관심이 없다는 것입니다. 관심있는 사람들이 결정해야합니다. 경험은 중요한 요소입니다. 좋은 결정을 내리는 데 시간이 걸립니다. 따라서, 투표를 통해 당신은 거버넌스에 전념하고 있으며 그렇게 함으로써 경험을 쌓았음을 보여줍니다. 그러므로 당신의 다음 투표는 조금 더 중요 할 것입니다. 'JP는 우리가 이미 가지고있는 지분을 가중 시스템에 추가 / 강화시킬 것이라고합니다. Todor : '내가 이 일을하기 위해 많은 제약이 필요하다는 것을 언급 한 이유 중 하나입니다. 중량 수정 계수, 부식, 스테이크 금액, WIP의 상한 / 하한과 같습니다.