블록 체인이 포크되면 스마트 계약은 어떻게됩니까?

블록 체인 포크와 그 영향을 이해합니다

블록 체인 포크는 블록 체인이 두 개의 개별 체인으로 분할 될 때 발생합니다. 종종 네트워크의 프로토콜 또는 합의 규칙의 변화로 인해 발생합니다. 포크는 네트워크 문제 나 개발자와 광부들 사이의 불일치로 인해 계획 (소프트 포크 또는 하드 포크) 또는 우발적으로 계획 될 수 있습니다. 이러한 분할이 발생하면 포크 지점까지 모든 데이터는 두 체인에서 동일하게 유지됩니다. 그러나 포크 후 생성 된 모든 거래 또는 스마트 계약은 각 체인에서 독립적으로 처리됩니다.

스마트 계약은 코드 라인에 직접 작성된 용어로 자체 사전 계약입니다. 이 계약은 중개자의 필요없이 일단 배포되면 자율적으로 운영됩니다. 이 계약의 실행은 전적으로 기본 블록 체인의 상태 및 합의 메커니즘에 달려 있습니다.

스마트 계약이 어떻게 작용 하는가

블록 체인 포크 후, 포크 앞에 존재했던 스마트 계약은 두 체인에 존재합니다. 이는 계약이 블록 100에 배치되고 포크가 블록 200에서 발생하는 경우 두 체인 모두 동일한 기록과 동일한 계약을 블록 200까지 가질 것임을 의미합니다. 그러나 포크 후 계약과의 상호 작용은 발생하는 체인에만 영향을 미칩니다.

이것은 몇 가지 중요한 질문을 제기합니다.

• 계약은 두 체인에서 동일하게 행동합니까?
• 이것이 의도하지 않은 결과로 이어질 수 있습니까?
• 누군가이 복제를 악용하면 어떻게됩니까?

계약의 동작은 외부 데이터 소스, 이벤트 및 거래와 상호 작용하는 방식에 크게 좌우됩니다. 새 거래가 포스트 포스트로 계약에 전송되지 않으면 두 버전 모두 동일하게 유지됩니다. 그러나 한 체인 또는 두 체인의 활동이 재개 되 자마자 계약의 상태가 분기되기 시작합니다.

포크 체인의 계약 실행과 관련된 위험

하나의 주요 위험은 재생 공격 과 관련이 있으며, 한 체인에서 유효한 거래는 다른 하나에 대해 악의적이거나 실수로 반복 될 수 있습니다. 예를 들어, 사용자가 체인 A의 계약으로 ETH를 보내면 공격자는 체인 B에서 해당 거래를 재생하여 의도하지 않은 작업을 유발할 수 있습니다.

이를 완화하기 위해 개발자는 종종 재생 보호 메커니즘을 구현합니다. 하나의 일반적인 방법은 각 트랜잭션에 고유 식별자를 포함하여 두 체인을 구별하는 것입니다. 다른 접근법은 체인 당 다른 서명 또는 비스를 사용하는 것과 관련이 있습니다.

오라클 또는 외부 데이터 피드가 스마트 계약과 상호 작용할 때 또 다른 우려가 발생합니다. Oracles는 각 체인에 다른 입력을 제공하여 일관되지 않은 계약 행동을 초래할 수 있습니다. 개발자는 계약이 예측할 수 없을 정도로 포크 포스트로 변할 수있는 오프 체인 데이터에 의존하지 않도록해야합니다.

하드 포크 vs. 소프트 포크 : 스마트 계약에 대한 시사점

소프트 포크 의 경우 뒤로 호환성이 보존됩니다. 이전 소프트웨어를 실행하는 노드는 여전히 새로운 블록을 검증 할 수 있습니다. 즉, 스마트 계약은 혼란없이 계속 작동합니다. Soft Fork가 도입 한 변경 사항은 일반적으로 기능을 향상 시키거나 규칙을 강화하지만 기존 계약 로직을 변경하지는 않습니다.

반대로, Hard Fork는 후진과 호환되지 않는 변경 사항을 도입합니다. 이전 노드는 새로운 규칙에 따라 생성 된 블록을 검증 할 수 없습니다. 결과적으로, 하드 포크가 OPCODE, 가스 비용 또는 계약 실행 논리를 변경하면 스마트 계약이 예기치 않은 행동에 직면 할 수 있습니다.

개발자는 어려운 포크 전후에 계약을 철저히 감사해야합니다. Mythril 또는 Slither 와 같은 도구는 프로토콜 업그레이드로 도입 된 취약점을 감지하는 데 도움이 될 수 있습니다.

포크 동안 개발자를위한 실용적인 단계

포크가 임박한 경우 개발자는 다음 단계를 고려해야합니다.

• 프로토콜 변경 모니터링 : EIP (Ethereum 개선 제안) 또는 블록 체인 플랫폼과 관련된 유사한 문서로 업데이트됩니다.
• 기존 계약 감사 : 정적 분석 도구를 사용하여 새로운 프로토콜 규칙을 사용한 잠재적 취약성 또는 비 호환성을 감지합니다.
• 재생 보호 구현 : 의도하지 않은 체인을 가로 질러 거래를 복제 할 수 없도록하십시오.
• 테스트 테스트 : 실제 행동을 관찰하기 위해 포크 환경을 시뮬레이션하는 테스트 넷에 계약을 배치합니다.
• 사용자와 의사 소통 : 사용자에게 가능한 혼란에 대해 알리고 안정성이 확인 될 때까지 계약과의 상호 작용을 피하도록 조언하십시오.

포크 환경에서 분쟁 및 갈등 처리

블록 체인이 분할되면 어떤 체인이 '진정한'버전을 나타내는 분쟁이 발생할 수 있습니다. 이러한 경우, 스마트 계약은 각 체인에서 상충되는 결과를 실행하게 될 수 있습니다. 예를 들어, 분산 교환 계약은 어떤 체인의 토큰 잔액이 유효한 것으로 간주되는지에 따라 거래를 다르게 처리 할 수 ​​있습니다.

거버넌스 모델은 여기서 중요한 역할을합니다. 강력한 거버넌스 프레임 워크를 갖춘 프로젝트는 혼란을 최소화하여 어떤 체인을 지원할 것인지 투표 할 수 있습니다. 또한, 다중 서명 지갑이나 타임 락은 안전망을 제공하여 팀이 결정에 도달 할 때까지 계약 실행을 일시 중지 할 수 있습니다.

그러나 명확한 거버넌스가 존재하지 않으면 분쟁은 영구적 인 조각화로 이어질 수 있습니다. 개발자는 이러한 시나리오를 우아하게 처리하기 위해 비상 중지 메커니즘 또는 폴백 로직과 같은 우발 계획과 계약을 설계해야합니다.

FAQ

Q : 블록 체인 포크 후 스마트 계약을 삭제할 수 있습니까? A : 아니요, 일단 배포되면 자체 파괴 함수가 포함되지 않으면 스마트 계약을 삭제할 수 없습니다. 포크 후에도 두 체인은 그러한 기능을 통해 명시 적으로 제거되지 않는 한 계약을 유지합니다.

Q : 분산 응용 프로그램 (DAPP)은 포크 후 스마트 계약을 재배치해야합니까? A : 반드시 그런 것은 아닙니다. 포크 전에 배치 된 계약은 두 체인에 두 체인에 존재합니다. 그러나 DAPP 개발자는 각 체인의 업데이트 된 규칙 또는 기능에 맞춰진 새 버전을 배포하도록 선택할 수 있습니다.

Q : 다중 서명 지갑은 포크를 어떻게 처리합니까? A : 멀티시 지갑은 포크 후 두 체인에도 존재합니다. 한 체인에 대한 거래는 의도적 인 조치를 취하지 않으면 다른 체인에 영향을 미치지 않습니다. 우발적 인 크로스 체인 운영을 피하기 위해 키를 신중하게 관리해야합니다.

Q : 새로운 포크와 계약 호환성을 확인할 수있는 도구가 있습니까? A : 그렇습니다. OpenZeppelin Defender와 같은 플랫폼은 부드럽게 및 Mythx를 사용하면 개발자가 다가오는 포크 또는 업그레이드와 관련된 호환성 및 보안 문제에 대한 계약을 분석 할 수 있습니다.