다오사태를 해결하기 위한 방법은 이제 하드포크외에는 없습니다.
이더리움을 지지하는 커뮤니티 전반적으로 하드포크를 찬성하는 의견이 많은 것은 분명해 보이지만, 구체적으로 어떤 내용이 하드포크에 포함되어야 하는지에 대해서는 아직까지도 이견들이 존재하는 것 같습니다.
그런 이견들을 정리해 놓은 글입니다.
https://blog.slock.it/options-in-the-hard-fork-90e467483c0#.1rtibmwn2
3가지의 큰 주제가 있습니다.
1. 모든 차일드다오에 있는 이더를 다 포함할 것인가 아니면 공격다오(다크와 화이트)와 메인다오에 있는 이더만 포함할 것인가?
a) 모든 차일드 다오에 있는 이더까지 전부 포함.
다오공격이 있기 전에 정상적으로 처리한 스플릿에 포함된 이더까지 다 포함해서 하드포크를 한다는 것임.
7월16일까지 하드포크를 해야 안전함.
문제는 이들 차일드 다오에 있는 이더를 포함하는게 코드가 훨씬 복잡해지기 때문에 이들 차일드 다오에서 리펀드하는 것은 4주를 늦춘다는 것이 원래의 계획이었는데, 이것은 정상적으로 스플릿한 사람들에게 불공평하다는 주장이 있음.
b) 정상적 차일드 다오에 있는 이더 제외
오로지 공격다오와 메인다오에 있는 이더만 리펀드 시킴. 정상적인 차이드 다오에서의 리펀드는 원래의 다오코드로 처리할 수 있도록 함.
이 경우 하드포크를 비교적 안전하게 할 수 있는 날짜를 7월 21일까지 연장할 수 있음.
정상적 차일드 다오에 있는 이더는 약 34,000 이더인데, 다오코드를 사용한 공격에 재차 노출될 위험성이 있음.
2. extraBalace 에 있는 이더를 어떻게 처리할 것인가?
extraBlance 는 1:100 이상의 비율로 다오를 구매한 엑스트라 이더를 모아놓은 밸런스입니다. 여기에 344,907이더가 있습니다.
이미 지적했듯이, 모든 DAO 는 얼마에 구매했는지에 상관없이 모두 동일한 권리를 갖는 것으로 설정이 되어 있었고, 이미 거래소에서 많은 거래가 이루어진 상태에서 원래의 지불가격을 찾아서 리펀드를 처리한다는 것에 여러가지 난점들이 존재합니다. 다음과 같은 의견들이 있습니다.
a) 모든 이더수 / 모든 다오수 로 구한 값으로 모든 다오소유자에게 분배함.
이 경우 약 1.03: 100 (약 3% 추가 이더 지불) 비율로 이더를 분배. 1:100 으로 구매한 사람은 이익이지만, 그 이상의 가격으로 구매한 사람은 손해
b) 코인보유자의 투표로 원하는 곳에 기부하도록 함.
c) 명망있는 사람들의 멀티 시그 지갑에 넣어 놓고 이 사람들의 주관하에 이후에 처리하도록 함.
아직까지 이 역할을 하겠다고 나선 사람이 없음. 나중에 법적 책임을 져야 할 상황이 생길 수도 있음. 이 사람들에 신뢰문제...
d) 코인을 빼갈 수 없는 컨트랙에 묶어 놓고 이후에 보다 공정한 방식에 대한 합의가 이루어지면, 별도의 하드포크로 처리하도록 함.
c)와 d) 의 경우 extraBalance 를 실제로 지불한 원 주소 소유자에게 되돌려 줄 수 있음.
(@코람데오 님의 주장이 일부 반영된 것 같습니다)
3. 결정을 연기할 것인가 아니면 지금 하드포크를 할 것인가?
모든 경우에 가장 공정하게 분배가 이루어지게 하기 위해 좀 많은 시간을 들여서 하드포크를 할 것인지, 현재 가능한 최선의 선택을 해서 빠른 시간내에 처리해야 되는가하는 문제.
a) 신뢰할 수 있는 멀티 시그 지갑에 넣고, 이 지갑의 소유자가 이후에 수동으로 리펀드.
충분한 시간을 들여서 검토할 수 있음. 하지만 누가 이 지갑의 멀티시그를 가질 것인가하는 난제.
b) 2d 의 옵션과 마찬가지로, 당장 접근할 수 없는 주소에 이더를 전부 옮겨 놓은 다음, 이후에 별도의 하드포크로 분배
c) 지체없이 모든 것을 지금 당장 처리
이 글을 쓴 사람(크리스토퍼)은 1b 2b, 3c 를 지지한다고 밝히고 이것을 위한 하드포크 컨트랙트 내용을 다음과 같이 제시했습니다.
import "github.com/slockit/DAO/DAO.sol";
contract Refund {
DAO constant public mainDAO = DAO(0xbb9bc244d798123fde783fcc1c72d3bb8c189413);
uint constant public totalSupply = 11712722930974665882186911;
uint constant public totalWeiSupply = 12072858342395652843028271;
function withdraw(address donateExtraBalanceTo){
uint balance = mainDAO.balanceOf(msg.sender);
if (!mainDAO.transferFrom(msg.sender, this, balance)
|| !msg.sender.send(balance)
|| !donateExtraBalanceTo.send(balance * totalWeiSupply / totalSupply - balance)
) throw;
}
}
================================
이와는 별도로 비탈릭과 파운데이션의 공식적인 입장에 약간의 변화가 있었는데요, 직접적으로 하드포크가 어떤 방향으로 가야된다고 주도하는 입장이 아니라, "중립적으로" 솔루션들을 제시하는 역할에 한정하겠다는 것이었습니다. 최종적인 결정은 커뮤니티의 결정에 맡기겠다는 것이죠. 논리적으로는 옳은 것이라 보지만, 현재의 상황을 좀 더 불투명하게 만드는 요인이 되었던 것 같습니다. 그 덕분에 이번주에 이더 가격이 한번 더 폭락을 맞이했습니다.
하지만 위의 글에도 비탈릭이 자신의 주장을 강제하지는 않겠지만, 개인적인 의견임을 전제로 다음과 같이 정리했습니다.
1b, 2b, 3c
이유는
1. 7월21일까지 시간을 벌 수 있고, 코드를 더 테스트할 수 있다.
2. solidity 리펀드 컨트랙이 단순해지고, 그 만큼, 보안위험을 줄일 수 있다.
3. 멀티시그를 담당할 사람들의 리스크
4. 이더를 더 이상 홀딩시키지 말고, 이번에 다 처리하고, 무브온 하자.
==================
I will once again refrain from trying to personally force the hard fork decision one direction or another; however I personally recommend that the option that developers focus their efforts on implementing and offering as a choice to their users should be 1b/2b/3c just like Christoph recommends. My reasoning is:
- A 1b fork can be implemented on Jul 21, whereas 1a requires Jul 16 unless you want to increase the code complexity. This gives us five extra days of testing, substantially reducing security risks. Additionally, 1b ensures that the fork does not actively interfere in any splits or cause any ETH to be locked up longer than it would be in a no-fork scenario.
- The 1b option allows the solidity contract to be simpler, once again reducing security risks.
- 2c requires some privileged multisig and invites both legal risks for the multisig holders and bikeshedding opportunities as to who gets this status (as well as the requirement to find people willing to take on the role). 2b is better than 2a as it provides a nudge to donate to a pool that can provide compensation to anyone who loses out due to splitting edge cases, but without making this mandatory or forcing a privileged one at protocol level.
- I like 3c because it (1) avoids a privileged multisig, (2) gets the problem solved quickly so that the community can move on, and (3) avoids locking up anyone’s ETH longer than it would be in a baseline scenario.
==================
저의 개인적인 생각도 1b, 3c 가 바람직하다고 보지만, 2에 대해서는 만일 멀티시그를 담당하겠다는 사람이 나타나면, 2c, 그렇지 않다면 2b가 어쩔 수 없는 선택이 될 것 같습니다.
실제 하드포크는 최대한 테스트를 거쳐서 7월 18일 쯤 적용이 되는 것을 타겟으로 하지 않을까 봅니다.
그리고 또 하나의 큰 이슈는 어떻게 커뮤니티의 동의를 "측정"할 것인가 하는 것입니다.
하드포크에서는 채굴자의 해시파워가 주 결정권자가 아닙니다. 체인이 길고 짧고 하는 것에 의해 합의가 되는 것이 아니기 때문에, 누가 더 많은 사용자를 확보하는가가 관건이 됩니다. 일차적으로는 주요 거래소가 제일 먼저 떠오르는데, 거래소들도 대응계획을 공동으로 준비하고 있다고 합니다.
하드포크 실행직전부터 몇시간 동안 모든 거래를 중단시키고, 어느 쪽 체인이 대세가 되는지 확인한 다음 그 대세에 맟주어서 거래를 재개한다는 것입니다.
만일 두 체인이 어느쪽도 대세가 되지 못한다면, 이더1, 이더2 로 나누어서 거래를 재개하는 방안도 검토중이라고 합니다.
거래소도 이와 같이 결정권을 행사하기 보다는 대세를 따르는 쪽으로 가겠다고 한다면, 과연 어떻게 커뮤니티의 '대세'를 측정할 것인가 하는 문제가 여전히 남습니다.
이더와 다오를 가지고 베팅을 하는 계획을 준비중인 팀들이 있습니다.
코인을 거래할 수 없도록 묶는 기간 X 코인량 = voting power
을 기준으로 베팅을 해서 지지율을 보겠다는 것이죠.
이 투표에 대해서는 다른 글에서 다시 정리해보도록 하겠습니다.
