슈퍼마켓이나 공과금을 지불하는 매장에 줄을 서는 것이 과거의 일이더라도, 우리 중 일부는 누군가가 줄을 섰을 때 어떤 느낌인지 알고 있습니다. 대기열의 맨 앞부분입니다. 특히, 줄을 서 있는 다른 사람들에 비해 그들의 청구서의 가치가 훨씬 더 높기 때문이라면 더욱 그렇습니다. 분명히 이것이 서비스의 신속성에 관한 기준이 되어서는 안 됩니다. 이제 최전선으로 이동하는 이 사업은 이더리움 스마트 계약에서도 발생합니다. 주식 시장의 유사한 현상에서 이름이 유래된 선행 오류라고도 알려진, 더 높은 가스 요금을 지불하는 스마트 계약 거래는 그렇지 않은 거래보다 더 선호되는 경향이 있습니다. 전면 실행 취약점 분석 즉시 이 취약점은 잘못된 프로그래밍으로 인해 발생하는 것이 아니라 트랜잭션이 주문되고 'mempool'에서 블록에 추가되는 방식을 사용합니다. 빠른 돈을 벌고자 하는 일반 사용자와는 별도로, 채굴자들은 그러한 거래를 통해 이익을 얻는 경향이 있으며, 이것이 바로 채굴자들이 블록에 추가되기 전에 그러한 거래를 감시할 가능성이 가장 높은 사람들입니다. 실제로 일단 그렇게 하면 불공정한 금전적 보상을 위해 자체적으로 거래를 보내고, 결국 먼저 보낸 것이 아닌 블록에 추가됩니다. 여기서 명심해야 할 점은 높은 가스 가격으로 체결된 거래가 다른 거래에 비해 먼저 처리되는 경향이 있다는 것입니다. 이러한 선호도를 염두에 두고 공격자는 단순히 더 높은 가스 비용을 지불함으로써 경매, 거래 또는 ICO와 같은 이벤트의 결과를 자신에게 유리하게 변경할 수 있습니다. 프론트러닝 취약점이 어떻게 작동하는지 이해하기 위해 다음의 일반적인 예를 살펴보겠습니다. 이 예에는 Naman, Kaavya 및 Aishwarya라는 세 명의 배우가 있습니다. 나만은 먼저 다른 두 가지 문제를 해결하기 위한 스마트 계약으로 해싱 챌린지를 배포합니다. 이 해싱 퍼즐을 푸는 사람은 보상으로 10Ether를 얻게 됩니다. 이제 Kaavya는 먼저 해싱 솔루션을 찾아 자신의 스마트 계약에서 가스 요금으로 10 Gwei와 함께 보냅니다. 반면 Aishwarya는 조금 후에 답을 찾아 가스비로 100 Gwei를 사용하여 스마트 계약에 대한 정답을 전달합니다. 더 높은 가스 요금을 지불하기 때문에 Kaavya가 10 Ether 보상을 받는 대신 Aishwarya가 아래와 같이 보상을 받습니다. 쉽게 말하면 가스비의 가치에 따라 거래를 처리하기 때문에 선점, 즉 거래 주문 오류입니다. 즉, Kaavya가 Aishwarya보다 먼저 답변을 제출하더라도 아래와 같이 그녀는 노력에 대해 아무것도 얻지 못합니다. Aishwarya의 이 'jump in line'은 Kaavya 또는 다른 누구와도 잘 어울리지 않으므로 스마트 계약 코드에 대한 몇 가지 예방 조치를 고려해야 합니다. Frontrunning 취약점을 처리하는 3가지 방법 이제 이러한 손실을 방지할 수 있는 수정 방법이 있습니다. 즉, 우리는 10 Ether를 받아야 하는 거래로 하나의 거래를 잠글 수 있어야 합니다. 방법 1: 거래 카운터 거래 카운터를 사용하는 것은 다른 사람이 다른 방법으로 보상을 받는 것을 방지하는 가장 간단한 방법 중 하나입니다. 아래 추가된 코드에서 알 수 있듯이 해싱 챌린지를 먼저 완료한 사람이 커밋한 트랜잭션을 잠그는 트랜잭션 카운터가 추가되었습니다. 가장 먼저 수행한 사람만 보상을 받아야 하므로 모든 참가자에게 솔루션과 함께 값 0을 추가하도록 알립니다. 첫 번째 제시된 솔루션에 대해 txCounter의 현재 값이 0이 되므로 고정됩니다. 즉, 위의 예에서와 같이 Kaavya는 10 Ether의 보상을 받기 위해 자신의 솔루션과 0 값을 입력합니다. . 다른 사람이 이 작업을 수행하면 트랜잭션 카운터가 1보다 큰 값으로 증가되었으므로 솔루션이 허용되지 않습니다. 그때쯤이면 Kaavya에게 전달되어야 할 전체 10 Ether 보상이 Kaavya에게 올바르게 전달될 것입니다. 방법 2: 가스 한도 설정 이제 이 방법에서는 모든 거래에 대한 가스 한도를 설정하는 데 중점을 둡니다. 필요한 경우 하한과 상한이 모두 적용됩니다. 기억하실 수 있듯이, 거래는 해당 거래에 대해 지불된 가스 요금에 따라 주문됩니다. 이것이 순서를 완전히 제거할 수는 없지만 확실히 순서를 크게 줄입니다. 아래 코드를 보면 1 이하의 가스를 지불하는 거래는 모두 성사되지만, 더 많은 가스를 지불하여 선을 뛰어넘으려는 거래는 gasThrottle 수정자 덕분에 성사되지 않습니다. 이 경우 1 Wei 또는 Gwei가 해당 거래를 처리하는 표준 비용이 될 수 있으며 이것이 허용되는 전부입니다. 따라서 이 스로틀 덕분에 모든 거래의 가스가 크게 달라지지 않으면 특정 거래에 대한 우선권을 나타내는 문제는 발생하지 않습니다. 이러한 접근 방식에는 장점이 있지만, 지불하는 가스 요금은 향후 변경될 수밖에 없습니다. 오늘 높은 것이 몇 년 후에는 낮아질 것이기 때문에 나만은 항상 이것을 조심해야 합니다. 아니면 Aish는 잠시 기다려서 이러한 변화하는 가치를 활용할 수도 있습니다. 방법 3: 잠수함 송신 접근 방식 이제 앞의 두 접근 방식은 더 간단한 상황에서는 작동할 수 있지만 실제로는 전면 실행 취약점의 근본 원인, 즉 채굴자와 기타 악의적인 사용자 모두에게 거래 정보가 완전히 공개되는 근본 원인을 해결하지 못합니다. 두 당사자가 각 거래 정보에 접근할 수 있는 한 시스템을 조작할 가능성이 지속된다는 점은 분명합니다. 분명히 시간에 민감한 정보를 숨겨야 하는 방법이 필요하며 스마트 계약 라이브러리의 일부로 구현된 잠수함 전송 접근 방식을 제공합니다. LibSubmarine 이 접근 방식을 사용하면 채굴자나 일반 사용자가 실제로 활용할 수 없는 방식으로 거래 정보를 숨깁니다. 암호화는 소유자의 재량에 따라 블록에 추가되면 공개될 수 있는 이 정보를 보호하는 데 큰 역할을 합니다. 즉, 이 접근 방식이 완벽하지 않더라도 실제와 현실 모두에서 선점 행위가 발생하는 실제 이유를 해결하려는 의지로 인해 제공되는 보호 수준은 다른 방법에 비해 훨씬 뛰어납니다. 블록체인에서. 앞서가는 취약점을 회피하기 위한 다른 전략 물론, 이전 섹션에서 논의된 전략은 '선행' 취약성으로부터 스마트 계약을 보호하는 유일한 전략은 아닙니다. 사이드 체인을 사용하면 주문은 오프체인에서 이루어지고 정산은 오프체인에서 이루어집니다. 이 두 단계가 서로 다른 플랫폼에서 수행되므로 처리량이 증가하는 이점이 있을 뿐만 아니라 채굴자나 일반 사용자가 선두 취약점을 악용하는 데 필요한 정보를 얻지 못하게 됩니다. 또 다른 전략은 이론적일지라도 커밋-공개 체계에서 커밋된 특정 라운드에 대한 트랜잭션 순서를 무작위로 지정하는 것입니다. 이는 스마트 계약 논리를 사용하여 시행됩니다. 앞서 언급한 스마트 계약에 따라 주문이 결정되기 때문에 선두 주자는 이 접근 방식을 사용하면 선두에 설 수 없습니다. 마지막으로, 또 다른 접근 방식은 사용자가 주문을 받는 사람을 결정하는 가장 중요한 t 값에 대한 검증 가능한 지연 함수를 해결하는 의 구현을 포함합니다. 결과적으로 대부분의 블록체인이 사용하는 무작위 순서 시스템에서 벗어날 수 있어 선점 공격 가능성도 줄어듭니다. 주입 프로토콜

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch

스마트 계약의 선행 취약점을 해결하는 방법

너무 오래; 읽다

@dansierrasam79

Credibility

관련 기사