이 텍스트는 원래 이오스네이션의 CEO, Yves La Rose 그리고 Voice.com에 게시 9 월 9 일 0500 UTC. 여기에 전체를 다시 게시하고 있습니다.
최근 EOS DeFi 영역에서 많은 움직임이 있었기 때문에이 글을 쓰기 위해 제 생각을 모 으려고 노력하고 있습니다. 우리의 토론을 요약하고 싶었습니다. EOS Nation 텔레 그램 그룹 당신을 위해 읽기 쉬운 형식으로, 또한 나중에 참조 할 수있는 편리한 것을 가지고 있습니다.
폭로; 나는 두 가지 이유로 오늘 밤에 이것을 특별히 작성하라는 메시지를 받았다.
- 토큰 보유자가 오늘 저녁에 연락하여 MSIG 권한 목록에 EOS Nation을 추가 한 프로젝트가 사기 프로젝트라고 믿습니다.
- EMD 프로젝트가 사기를당한 것 같습니다.
제 목표는 가능한 한 가장 넓은 범위를 확보하는 것입니다. 따라서 복잡성 측면에서 이것을 단순하게 유지하려고 노력할 것입니다. 이러한 개념을 깊이 이해하는 사람들은 제가 특정 사항을 지나치게 단순화하고 있다고 느낄 수 있습니다. 그것이 나의 의도입니다.
감사 VS 오픈 소스
지금 EOS에서 보는 것은 계약 감사를 받거나 감사를 건너 뛰고 코드를 오픈 소스로 선택하여 누구나 감사 할 수있는 문을 본질적으로 여는 프로젝트입니다. 두 가지 장점과 단점이 있습니다. 요점은 일반적으로 둘 중 하나를 봐야한다는 것입니다.
잠재적 인 위험 신호는 프로젝트가 둘 다하지 않는 경우입니다.
또한 중요한 점은 감사를 수행하거나 오픈 소스 코드를 사용한다고해서 코드 내에서 문제가 발생할 위험이 제거되지 않는다는 것입니다 (의도적이든 아니든). 단순히 위험의 일부를 완화하고 심지어는 크게 줄입니다. 어느 정도는 있지만 완전한 증거는 아닙니다. 둘 다 초기 신뢰 기반을 구축하여 토큰 보유자와의 관계를 개선하는 수단입니다. 내가 함께 일한 EOS에 대한 감사 서비스를 제공하는 회사는 Slowmist, PeckShield, EOS42 및 Sentnl입니다. 이 네 사람과 함께 일한 경험을 바탕으로 그들이 유능하고 신뢰할 수 있다고 생각합니다. 그러나 반복해야합니다. 감사는 위험을 제거하지 않고 상당한 정도까지 완화합니다. 이것을 기억하십시오. 감사를 수행하는 프로세스는 며칠 동안 지속될 수 있으며 코드의 잠재적 인 허점을 없애기위한 것입니다. 프로젝트가 감사를 수행하지만 감사되지 않은 다른 버전의 코드를 배포하면 의미가 없습니다. 배치 된 코드가 감사 코드의 해시와 일치하는지 확인하십시오. 일반적으로 감사자는 승인 스탬프를 제공 할 때이를 언급으로 추가합니다 (예 :이 코드를 감사했으며 배포 된 코드가 감사 한 해시와 일치 함).
MSIG VS 단일 소유자
이건 까다로운 일 이니 참아주세요. MSIG는 MultiSignature의 약자입니다. 이는 단순히 특정 계약을 변경하기 위해 둘 이상의 당사자에 대한 요구 사항을 추가하는 것입니다. 코드 수정에서 계약 자체 내에서 함수 실행에 이르기까지 변경 사항이있을 수 있습니다. MSIG는 여러 가지 이유로 훌륭합니다. 주된 것은 특정 계약에 대한 유일한 권한을 포기하는 것입니다. 소유권을 분산시키는 것입니다.
EOS에는 MSIG와 함께 활용할 수있는 매우 강력한 기본 계층 권한 기능 세트가 있습니다. 조정해야하는 두 가지 주요 항목은 임계 값과 무게입니다.
- 임계 값은 도달하는 기준으로, 계약에 대한 권한을 갖기 위해 달성하거나 초과해야하는 구체적인 숫자입니다.
- 가중치는 각 참가자에게 할당 된 값입니다. 가중치를 더하면 임계 값이 충족되는지 확인할 때 계산됩니다.
예를 들어, 설정된 임계 값이 3 인 계약이 있다고 가정 해 보겠습니다. 권한 집합에는 각각 가중치가 하나 (1) 할당 된 5 개의 계정이 있습니다. 계정을 변경하려면 해당 계정 중 세 (3) 개가 임계 값 설정을 충족하기 위해 합의에 있어야합니다.
각 EOS 계정에는 소유자 키와 활성 키가 있습니다.
소유자 권한은 원하는대로 할 수 있습니다.
- 활성 키 및 권한 집합 변경을 포함합니다.
- 대부분의 경우 활성 권한은 eosio.code뿐입니다. 그래서 계약 자체.
대부분의 프로젝트에서 MSIG는 소유자 수준에서 볼 수 있지만 반드시 활성 수준에서는 볼 수 없습니다. 이건 괜찮아. 여기가 조금 까다로워지는 곳입니다…
MSIG 권한 목록에 모든 계정을 추가 할 수 있습니다. 이는 해당 계정 소유자의 동의 나 지식이 필요하지 않습니다.
이것이 왜 중요한가요? 우선, MSIGd 계정이 있으면 어느 정도 보안 계층이 추가되지만 (위에서 언급했듯이 계약 소유권이 분산됩니다), 다른 기준을 따르지 않으면 피상적 일 수 있습니다. MSIG 계정이 본질적으로 계약에 문제가 없음을 의미하지는 않습니다.
- 코드가 감사되었거나 오픈 소스인지 항상 확인하십시오.
- MSIG 참가자가 알려져 있고 신뢰할 수있는 엔터티인지 항상 확인하십시오.
- 항상 임계 값과 가중치 설정을 확인하십시오. 합의에 도달하기 위해 변경을 승인해야하는 다른 엔티티의 수
동의에 대해서는 다소 부적절합니다. 프로젝트가 특정 단체가 MSIG의 당사자가되기를 원하는지 여부를 물어 보는 것은 좋은 형식입니다. 예의 바르게 생각하세요.하지만 지금 아시다시피 그럴 필요는 없습니다. 우리가 각 프로젝트를지도하고, 지시하고, 멘토링하고, 검토 할 방법이 없습니다. 우리는 이것을 할 수 없습니다. 하루에 충분한 시간이 없습니다.
MSIG 목록에 있다는 것은 프로젝트의 본질적인 보증이 아닙니다.
EOS Nation에서 우리는 토큰 소유자와 개발자를위한 일반 서비스로서 계약을 분산시키는 것을 돕기 위해 프로젝트의 MSIG 목록에있는 것을 수락하는 입장을 취했습니다. 예를 들어 어느 누구도 자산을 임의로 이동할 수 없도록 어느 정도 보장하는 데 도움이되므로 위에 명시된 기준이 충족 될 때 그렇게 할 수 있습니다. 그러나 생태계가 성장하고 더 많은 프로젝트가 배포됨에 따라 더 이상 확장 가능하지 않은 지점이 있습니다. 따라서 동의가 필요하지 않다는 이전 의견. 언젠가는 프로젝트가 신뢰할 수있는 엔터티를 할당하고 변경이 필요한 경우에만 연락하는 것이 불가피합니다. 검토 프로세스가 승인되면 그 시점에 완료됩니다. 절대적으로 필요한 경우가 아니라면 일반적으로 코드를 수정하지 않기 때문에 이런 일이 발생하지 않을 수 있습니다. 토큰 보유자가 위에서 작성한 내용을 이해하는 한 괜찮습니다. MSIGd 계정은 감사와 마찬가지로 위험이 없음을 의미하는 것이 아니라 가능한 위험을 제거하는 것이 아니라 가능한 위험을 완화하기위한 추가 보호 계층 일뿐입니다.
나는 기사의 특정시기에 대한 공개를 제공함으로써이 기사를 시작했다.
- 유용성이 거의없고 의사 소통이 좋지 않고 토큰이 의심스럽고 익명의 팀이 있고 자산 가치가 떨어지는 프로젝트는 사기가 아닙니다.
- 내가 알 수있는 한 EMD는 감사를받지 않았고 오픈 소스가 아니며 소유자와 활성 키는 MSIGd가 아니라 동일했습니다. 이것은 막을 수있었습니다.
읽어 주셔서 감사합니다. 이것이 이러한 개념을 이해하는 데 도움이 되었기를 바라며, 생태계가 다음 성장 단계에 접어들 때 정보에 입각 한 결정을 내리는 데 도움이되기를 바랍니다.
“우리는 우주의 리더 중 하나로서 혁신을 지원합니다. 혁신은 높은 보상과 높은 위험의 기회를 제공합니다. 일부 프로젝트는 달에 도달하지만 일부는 부족합니다. 항상 그에 따라 위험을 관리하십시오. " – Binance CEO Changpeng Zhao