@timcliff's Witness Hardfork Approval Standards v0.1 -번역

@timcliff 증인의 글이 괜찮아서 번역해봅니다. @timcliff 증인은 현재 2위 증인이며 스팀잇을 위해 여러가지 활동을 하는 것으로 알고 있습니다. 이후에 그에 관해서 포스팅을 할 수 있도록 하겠습니다
중간중간 오역이 있을 수 있지만, 알려주시면 즉시 수정 할 수 있도록 하겠습니다.
시간이 되시면 원문을 직접 읽어보는 것도 좋을 것 같습니다.
출처 : @timcliff's Witness Hardfork Approval Standards v0.1

---

나는 하드포크 20의 결과에 정말 만족합니다.
그것은 분명히 그 혼란이 일어난 후에 말하기에는 말도 안 되는 말이지만, 설명해드리겠습니다.

하드포크 승인에서 증인의 역할
하드포크 20 이전에는 하드포크를 승인하기 전에 코드를 테스트 하고, 검토해야 할 증인들의 책임에 포커스를 두지 못 했습니다. 또한 증인들이 개발팀이 하고 있는 진행상황을 방해하지 않고 변경을 지지하거나, 푸쉬하는 효과적인 방법이 없었습니다.

하드포크 20 이후에는 증인들의 하드포크 승인에 관한 대화가 크게 변경되었습니다. 이것은 중요한데, 다음 큰 하드포크 (SMT)는 하드포크20보다 10배는 복잡할 것이고, 많은 문제가 발생 할 수 있기 때문입니다.

우리는 하드포크 20에 발생한 많은 문제점에 관심을 갖게 되어, 해결 방법에 대해서 이야기를 나눌 수 있었습니다.

SMTs
SMT 출시는 외부 사람들로부터 많은 관심을 받을 것 입니다. 그리고 SMT 출시가 성공하지 못 할 경우에도 많은 관심을 가질 것입니다. 그리고 개발자는 다른 곳으로 (예: 다른블럭체인으로) 비지니스를 이어갈 것이고, 스팀을 주변에 추천 하지 않을 것입니다.

하지만 SMT가 성공한다면, 스팀을 기반으로 하는 많은 사업을 유치할 수 있는 기회가 생깁니다. 이 기업들의 스팀에 많은 자본과 신규 사용자들을 끌어들일 수 있는 잠재력을 가지고 있습니다.

우리는 SMT의 출시가 큰 성공을 거두길 바라며, 이것을 위해 변화가 필요합니다.


하드포크 승인 표준 v0.1
이 게시물은 하드포크 20에 겪었던 문제와 같은 또 다른 사건을 막기 위해 무엇이 달라질 필요가 있는지에 대해서 대화를 시작 했습니다. 많은 증인들이 앞장 서고 있습니다.

향 후, 하드포크의 승인, 거부 판단 기준은 다음과 같습니다. 어떤 기준도 새로운 문제를 완전히 막을 수 없지만, 이들의 기준을 따름으로써 문제가 메인 네트워크에 발생하기 전에 문제를 발견할 기회를 늘림으로써, 새로운 장애의 위험을 크게 줄일 수 있다고 생각합니다.

이 표준은 초안입니다. 주신 피드백을 사용하여, 다음 하드포크에 승인하기 위해 사용할 버전 1.0의 표준을 작성할 예정입니다.


하드포크 제안
개발 팀은 그들이 계획하고 있는 변경 사항에 대한 상세한 제안서를 작성해야 합니다. 그 제안서는 그들이 무엇을 바꿀 것인지, 그 이유를 분명히 설명해야 한다.

이해 관계자는, 그 제안에 대해서 토론하고, 그 찬반 양론을 표명해야 한다.
(SP를 보유한 모든 사용자는 이해 관계자로 간주 합니다.)

나는 증인으로서 이해관계자들의 제안과 피드백을 평가 할 것이고, 그 제안에 대한 찬성/반대를 의견에 대해서 공개적으로 발표 할 것입니다.

참고:제안에 대한 나의 지지가 최종적으로는 하드포크를 수락한다는 것을 의미 하지 않는다는 것을 구별하는 것이 중요합니다. 최종 투표가 열리기 전에, 내가 하드포크를 거부할 수 있는 많은 요인들이 있습니다.

제안된 변경에 근본적으로 반대하는 경우, 하드포크를 수락하지 않는 것을 명확히 하고, 가급적이면 빠르게 이유를 설명합니다.

1. 개발자는 필요한 경우 자신의 제안을 조정할 수 있습니다.
2. 개발자는 승인에 대한 합의가 없으면, 코딩으로 시간을 낭비하지 않습니다.
3. 이해 관계자는, 내 의견에 반대하다면, 증인 투표를 조정할 수 있습니다.

놀라운 변화가 아닐 때
원래 제안서에 포함되지 않은 기능을 하드포크에 추가/변경 포함할 경우, 또는 제안서의 일부가 변경이 크게 변경 또는 삭제된 경우는 개발 팀은 제안서를 다시 변경 사항을 다시 알려야 합니다. 그리고 개정안은 원래의 제안과 같은 검토 과정을 따라야 합니다.


개발의 추적
GitHub에는 모든 변경에 있을 때 마다 이슈가 있어야 합니다. 이 이슈는 변경사항과 그 변경이유를 설명해야 합니다. 증인은 GitHub에서 진행되는 개발 상황은 인지하고 있어야 합니다.

또, 개발팀은 증인이 하드포크에 포함된 모든 변경을 확인할 수 있도록, 하드포크 내의 모든 문제의 명단을 증인에게 제공할 수 있어야 합니다.

추가된 질문과 우려 사항
증인과 이해관계자는 GitHub의 문제를 통해 특정 변경 사항에 대해 질문 할 수있는 기회가 있어야 합니다. 개발팀은 GitHub 문제에 문서화 된 모든 합리적인 질문과 우려사항에 응답해야합니다.


자동화 된 테스트
Steem 블록 체인 코드에는 이미 광범위한 자동화 테스트가 있습니다 (개발 팀에서 유지 관리됩니다) 업데이트가 의도 한대로 작동하는지 확인하고 새로운 변경 사항은 기존 기능을 저하시키지 않습니다.

이러한 자동화 된 테스트는 기능이 변경됨에 따라 확인해야하는 새로운 사례를 설명하기 위해 계속 업데이트되어야합니다. 증인 및 이해 관계자는 새로운 변경 사항을 체크인 할 때 자동 테스트에 의해 설명되지 않는 테스트 사례가있는 경우 문제를 제기해야합니다.


테스트 환경
모든 변경사항이 메인넷에 전개되기 전에 모든 변경 사항을 충분히 검증 할 수있는 테스트 환경을 제공하는 것이 중요합니다. 이것에 대한 많은 측면이 있습니다. 아래에서 개요를 설명합니다. 또한 할당 된 시간에 모든 다른 시나리오를 충분히 커버 할 수 있도록 여러 테스트 넷을 병렬로 실행해야 할 수도 있습니다.

MVP 확인
테스터는 테스트 넷에서 하드포크에 포함 된 모든 변경 사항의 "최소 실행 가능 제품"(MVP) 기능을 검증 할 수 있어야합니다.


테스트넷 툴 인프라
이것은 테스트넷에서 제대로 테스트 할 수있는 가장 중요한 측면 중 하나입니다. 우리는 메인넷에있는 것과 일치시키기 위해 테스트넷에 대한 도구의 인프라가 필요합니다.

• 콘덴서(steemit.com) 인스턴스, 블록 탐색기 (예 : testnet.steemd.com), cli_wallet 기능 및 SteemConnect (예 : testnet.steemconnect.com)가 포함됩니다.
• 모든 개발자 라이브러리 (Steem Python, Steem-JS, Beem 등)를 사용하여 테스트넷에 연결하고 인터페이스하는 방법에 대한 지침이 제공되어야합니다.
• 노출 된 새로운 블록 체인 API 메소드가있는 경우 해당 메소드에 액세스하여 사용하는 도구 및 / 또는 라이브러리가 제공되어야합니다.
• 이상적으로 모든 제 3 자 웹 사이트와 도구 (SteemPeak, Steem Monsters, Vessel, Voting Bots, SteemAuto 등)는 사용자가 테스트넷에서 실험 할 수있는 테스트넷 또는 샌드박스 버전의 제품을 만들어야합니다.

테스트 계획
steem.chat 목격자 채널에서 @ned는 다음과 같이 질문했습니다.

The next layer that’s just as or more critical is How standards are met — what is the witness’ standard for verifying that testing is done? What qualifies sufficient testing?
What qualifies an audit? What qualifies qualifying that a qualified audit was done?

이에 대한 나의 제안은 개발 팀이 커뮤니티에 테스트 계획을 제공해야 할 책임이 있다는 것입니다. 이 테스트 계획은 모든 변경 사항이 올바르게 작동하는지 확인하기 위해 코드 릴리스 이전에 수행 한 문서화 된 일련의 테스트 여야합니다. 테스트 계획은 테스트넷의 커뮤니티 테스터가 실행할 수 있어야합니다.

감사자 와 테스터는 테스트넷의 테스트 계획에서 테스트 단계를 실행하여 하드포크의 적절한 기능을 검증 할 수 있어야합니다.

커뮤니티 회원은 문서화 된 테스트 단계에서 다루지 않는 사례를 생각할 경우 추가 테스트를 수행해야합니다.


포크 전 병렬 작동 테스트
새로운 노드 코드가 일부 노드에는 설치되지만 모든 노드가 아닌 시간이 있고 하드 포크 시간은 아직 발생하지 않습니다. "병렬 작업"기간이 계획되지 않은 포크를 포함하여 예기치 않은 문제를 일으키지 않도록하려면이 시나리오를 테스트 계획에 포함해야합니다.
(노드간 버전이 다른 경우에도 테스트가 필요하다)


"Mainnet"과 동인한 조건의 시뮬레이션
테스트넷은 가능한 한 메인넷에서 발생할 실제 조건을 시뮬레이션해야 한다. 변경사항이 생중계되기 전에 적절히 작동하는지 확인하기 위해 테스트넷에 정확하게 복제할 수 없는 실제 조건이 있는 경우, 제한사항은 관련된 위험과 함께 미리 커뮤니티에 적절히 전달되어야 한다.

가능한 한 많이 테스트 네트워크는 메인 넷에서 발생할 실제 조건을 시뮬레이션해야합니다. 실시간으로 가기 전에 변경 사항의 올바른 작동을 완전히 검증하기 위해 테스트 네트워크에서 정확하게 복제 할 수없는 실제 조건이있는 경우 제한 사항이 위험과 함께 미리 커뮤니티에 제대로 전달되어야합니다.


실제 메인넷과 동일한 조건의 시뮬레이션.
가능한 한 많이 테스트 네트워크는 메인 넷에서 발생할 실제 조건을 시뮬레이션해야합니다. 변경 사항의 올바른 작동을 완전히 검증하기 위해 테스트 네트워크에서 정확하게 복제 할 수없는 실제 조건이있는 경우 제한 사항과 위험을 함께 미리 커뮤니티에 제대로 전달되어야합니다.


충분한 테스트 시간
테스터가 모든 변경 사항을 확인할 수 있도록 테스트넷이 충분한 시간 동안 실행되어야 한다. 테스트가 실행되는 데 필요한 시간 (예 : 새 게시물이 생성 된 후 7 일이 경과 한 후 새 게시물에 대한 유효성 확인)이 필요한 변경 사항의 경우 테스트넷의 인스턴스를 중단없이 실행해야만 해당 엔드 - 투 - 엔드 기능을 확인할 수 있습니다.

이전 테스트 결과를 무효화하는 패치가 릴리스된 경우 다시 테스트해야 하는 기능을 재검증하기 위해 추가 시간이 제공되어야 합니다.

테스터는 최적의 테스트를 위해 주어진 시간을 사용할 책임이 있습니다.


증인의 테스트넷 참여
증인은 블록 생성 노드를 실행하여 테스트넷에 참여해야합니다. 이를 통해 노드에서 포크가 예상대로 발생하는지 확인하고 포크에 포함 된 감시 기능 관련 기능을 확인할 수 있습니다. 이와 함께 증인은 테스트를 용이하게하기 위해 가격 정보를 제공하고 적절한 증인 매개 변수를 제출해야합니다. 이해 관계자는 테스트넷 목격자 노드를 실행중인 테스트넷의 증인에게 투표해야합니다.


14일 동안 안정적인 빌드 실행
테스트넷은 심각한 문제가없는 하드포크 이전 최소 14 일 동안 안정된 빌드를 실행해야합니다. 패치를 재 배포 해야하는 치명적인 문제가 발견되면 14 일 카운트 다운을 다시 시작해야합니다.


문서 업데이트
스팀 블록체인에 대한 문서는 변경 사항과 함께 최신 상태로 유지되어야합니다.

여기에는 다음이 포함됩니다.

• 새로운 API 방법은 개발자 포털에 문서화됩니다.
• 기존 API 방법의 변경사항은 개발자 포털에 문서화됩니다.
• 새로운 steemd 매개 변수가 문서화되고 설명됩니다.
• config.ini 파일에 대한 모든 변경 사항은 문서화되고 설명됩니다.
• 빌드 프로세스에 대한 모든 갱신 사항은 릴리스 정보에 설명되어 있습니다.
• 필요에 따라 백서(whitepaper), 청서(bluepaper) 및 steemit.com FAQ를 업데이트하는 이슈가 만들어집니다.
• 일반적으로 예상되는 작업 (예 : 트랜잭션의 RC 비용 계산 방법)에 대해서는 개발자 포털에서 제공됩니다.
• 복잡한 새 기능 (예 : 새로운 RC 시스템)에는 wiki 기사 또는 스팀 블로그 게시물 (예 : RC 대역폭 시스템)이 있어야 합니다.

커뮤니티 기대
Steemit 개발팀은 성공하는 데 중요한/상업적인 역할을 담당하지만, 증인과 이해당사자도 이에 대한 책임이 큽니다. 다음을 포함하여 우리가 책임져야 하는 몇 가지 사항이 있습니다.

• 모든 사람은 테스트넷에서 테스트해야합니다. 테스트는 노력입니다. 테스트 환경에서 다양한 일을 시도하는 사람들이 많을수록 더 많은 시나리오를 다루고 더 많은 문제를 발견하게됩니다.
• 이해 관계자는 잘못된 것을 발견하면 적절한 GitHub 저장소에 이슈를 제기해야합니다. 이슈를 만드는 것이 어렵다면, 대신 증인이나 그 대신에 만들 수있는 다른 공동체 구성원에게 연락해야합니다. 이슈의 문제가 심각한 경우 GitHub 에서 심각성을 전달해야합니다.
• 증인들은 개발 팀이 무엇인가가 이슈가 발생하면, 가능한 한 일찍, 분명하게 알릴 필요가 있습니다. 다시 말해 증인이 하드포크를 승인하기 위해 수정해야하는 이슈가 있는 경우 문제가 해결 될 때까지 하드포크에 투표하지 않았음을 분명히해야합니다. Steemit과 증인 모두 GitHub (위 참조)에보고 된 내용을 기반으로 존재하는 모든 이슈를 명확하게 파악해야합니다.

최종 거부권
궁극적으로 증인은 하드포크에 대해 최종 거부권을 갖습니다. 문서화 된 표준이 모두 충족되었다고해도, 표준에 포함되지 않은 네트워크/ 이해 관계자에게 위협을 주는 것을 발견하다면, 증인은 '아니오'라고 투표하여 하드포크를 거부하거나 지연시킬 수 있습니다.

증인 투표 기준은이 능력을 어제하기 위한 것이 아니지만 증인은 하드포크를 거부 할 근거를 (기준을 통해) 미리 명확하게 하기 위해 최선을 다해야 합니다.

IMO, 의사 소통이 가장 중요합니다. 증인이 하드포크에서 '아니오'라고 투표한다면, 개발 팀과 이해 관계자가 최소한의 낭비 된 자원으로 적절하게 조정할 수 있도록 최대한 빨리 알려야 할 책임이 있습니다.


진화하는 표준
이러한 표준은 시간이 지남에 따라 계속 발전 할 것으로 예상됩니다. 위에서 언급 한 리스트는 모든 가능한 문제들을 막지 못할 것이지만, 그것은 우리가 현재 보다 큰 진전입니다. 가장 중요한 것은, 그것들이 우리가 다음 하드포크를 가질 때쯤에는 만족될 수 있다고 믿는 기준이라는 것이다.

이러한 표준은 시간이 지남에 따라 계속 발전할 것으로 예상됩니다.


피드백 요청
이해 관계자가 증인의 표준을 지지하고 있는지 여부와그리고 개발팀이 증인의 기준에 기꺼이 적응할 의사가 있는지 여부는 이것을 성공시키기 위한 두 가지 중요한 요소이다. 우리가 올바른 정당을 만들기 위해 적절한 균형을 찾을 수 있기를 바랍니다.

아래 의견에 의견을 보내주십시오.

---

생각보다 내용이 많아서 오래 걸렸네요 ㅠ
제가 번역을 전문적으로 하는 사람이 아니기 때문에, 오역이 있을 수 있고 일부 잘못 된 내용을 전달 할 수도 있습니다. 따라서, 가급적이면 위에서 언급했던 원문을 봐주시고, 시간적인 여유가 되지 않는 다면 가벼운 마음으로 제가 번역한 내용을 보시면 될 것 같습니다.

그리고 저도 테스트넷에 참여를 위해 해당 모임에 조인을 하였습니다..^^