안녕하세요 클레이튼 블록내 Tx 순서는 Go map에 의해 랜덤으로 알고있습니다.
블록 데이터 분석중 0xd2349c02ff12b492ce2a06f00dab2fb7898e0798 해당주소
[Klaytnscope]
로 가는 Tx들 보면 매번 블록에 첫번재로 담기던데,
GC에서 의도적으로 1번으로 담는건지 아니면
블록 내 Tx의 순서가 map에 의한 랜덤 소팅이 아닌건지 궁금합니다
감사합니다
0x9ae2eabc92cbccf8704cb4af052adb32c1ceb79c 주소추가합니다
맞아요…이상하게 꼭 블럭 처음 순서에 담기네요.
GC에서 의도적으로 하는 행동같은…의심이…
1번 담기는걸 이용해서
시세차익 컨트랙트 호출로 대량 이득을 취하고 있고요.
0x87d825de6a0f0b26daf1ff965f8ff17efed00d57
여러 노드에 동시에 넣는 시세차익 봇 보다 빠르게 꼭 처음 에 담기는데…
먼가 이상하네요.
0x9ae2eabc92cbccf8704cb4af052adb32c1ceb79c 가 성공한 차익거래는 전부 블럭의 첫번째에 담기는군요.
제가 시간 관계상 자세히 보지는 못했지만 해당 주소가 front running을 한다고 판단하기에는 아직 어려울거 같습니다.
링크주신 0xd2349c02ff12b492ce2a06f00dab2fb7898e0798 주소의 Scope 페이지를 탐색해보시면 2페이지에 대량의 revert 가 발생했으며, 3페이지부터는 비슷한 시간대에 한 블록에 일찍 담기기위해 대량의 트랜잭션을 배포했던 것을 보실 수 있습니다. 즉, front running 기법을 가진 사용자의 패턴이라고 판단하기 어렵습니다.
일정 순간 해당 주소의 tx가 타 블록보다 일찍 담긴 현상은 spam throttler 등의 영향으로 가능할 것도 같은데, 이 부분에 대해서 추가 분석이 필요합니다. 그리고 만약 spam throttler의 영향으로 보더라도 이는 Job scheduler에 의해 랜덤성을 가진채 순서가 배정될 것이기에 머신의 스펙이나 상태의 영향을 많이 받아 determinstic하게 이용하기 어려울 것입니다.
단기간에 발생한 부분이 아니라 확률이 아주 낮을 것이라 판단되는 장기간 이상 구간을 공유해주신다면, 저도 더 분석해 보도록 하겠습니다. 감사합니다.
1개의 좋아요
spam throttler 의 경우 target address 의 revert여부로 카운트 하는걸로 알고있습니다. 영향이 어떻게 받는 지 공유해주시면 저도 분석/공부하는데 도움될 것 같습니다!
0x9ae2eabc92cbccf8704cb4af052adb32c1ceb79c 의 fee delegated된 tx들을 보면 대부분 ( 20개중에 1개꼴정도 제외) 모두 1번째에 담기고있습니다.
txpool에서 propose할 block을 선택할 때 account별로 수집된 map에서 heap을 만들어 selection하는 로직을 봤었는데요,
Golang에서 map의 key iteration이 매번 랜덤으로 바뀌므로 당연히 블록내 Tx 순서는 랜덤이 맞다고 생각합니다
(그래서 업데이트전 대량 쏘던 봇들이 많이 쏜 이유였구요)
위에서 언급한대로 0x9ae2eabc92cbccf8704cb4af052adb32c1ceb79c 의 주소를 보면 Tx를 단 한개만 쏘는데
거의 대부분 1번 슬롯을 차지해서 우연으로 보기는 힘들어보여서 궁금해서 올렸습니다!
일부분만되더라도 말이안된다고 생각하긴해서요. 30개정도 담기는 블록에서 1개의 Tx만 쏴서 1등하는 확률도 매우 적다고 생각하는데,
그 확률을 여러번 보여주니 더더욱 말이안되서, 랜덤 셀렉션 말고 다른 로직이 있나, 놓치는게 있나 궁금하네요
0x9ae2eabc92cbccf8704cb4af052adb32c1ceb79c 이 주소로 옮겨서 차액거래를 하고있어서 한번 봐주시면 좋을 듯 합니다.
프론트 러닝의 영역 외의 노드가 관여되지 않고서는 설명되지 않을 확률이라 생각합니다
1개의 좋아요
추가로 대량 revert의 원인은 fee granter에 잔고가 없던걸로 보입니다
아! Spam throttler는 영향이 없을 것으로 보입니다. 지금 현재 개발중인 버전과 제가 조금 착각을 했네요. 현재 개발중인 버전에서는 각 노드가 먼저받은 tx를 먼저 블록에 담거나 전파하는 기능이 추가됩니다. 이 때는 throtthler된 tx가 txpool 추가되는 goroutine과 타 노드로 부터 tx를 전파받아 txpool에 추가하는 goroutine이 txpool lock을 잡는 타이밍에 따라 우선 순위 경쟁이 될 수 있습니다. 그런데, 지금 Cypress 노드가 사용중인 버전과는 관계 없겠네요.
저도 링크주신 내용에서 연속적으로 1등이 되는 확률은 낮다고 생각됩니다. 다만, 해당 사용자가 front running 방법이 있다면 시간상 얼마 차이나지 않는 (1시간 미만) 앞쪽 블록에서는 그런 front running 기법을 사용하지 않고 대량을 트랜잭션을 보내는 방법을 사용한 것이 이상하다고 생각합니다. 물론, 앞으로 이 사용자가 소수의 tx로 1등을 차지한다면, 의심해볼 여지가 있어보입니다.
여유가 될 때 저도 확인해보도록 하겠습니다.
0x9ae2eabc92cbccf8704cb4af052adb32c1ceb79c
쓰레드 중간부터 바뀌었다는 위 주소에서는 한블록에 여러 Tx를 날리는 경우가 존재하지않았습니다.
예전링크 address 말고 해당 주소를 보셔야 할 것 같습니다.
…
이전주소에 한시간 미만 앞쪽 블록에서 대량의 Tx 역시 오류에 의한것이지, 딱히 의도적으로 많이 보내지는 않았네요.
프론트러닝이 중요한건 아닌것같습니다. 다른 봇들도 모두 프론트러닝중이니까요. 앞으로 소수의 tx로 1등을 차지하는게 아니라, 단 2번 아니 넉넉히 잡아서 연속으로 5번이라도 1Tx로 1등을 차지하는건 문제가 있어보입니다.
중요한 포인트는, Txpool에서 tx를 선택할때 로직대로 랜덤이 맞냐 아니냐인 것 같습니다.
제가 이해한대로 랜덤이 맞다면 해당 계정이 CN과 연관이 있을거라는 의심을 지우기 힘들것같습니다.
이번 하드포크후 부터 이런 현상이 있었던건 같습니다…
블록 1번 등록이 가능하면 개발자가 조금만 노력하면 2번도 3번도 가능할것같으로 판단되네요…
해당 문제는 좀 심각한 문제일꺼라 생각됩니다. 의도적인 위치 tx날려 악의적으로 사용할수도 있고
지금도 독식에 가까운 시세차익으로 하루 몇만개의 클레이를 이득이 발생하고 결국 시장 매도가
발생 클레이 홀더에 악영향이 갈것으로 생각되네요.
위 주소 TokenTransfer를 보시면 거래가 발생한 블럭에 항상 1번으로 들어갑니다.
개인적으로 아비트라지를 먹는거에대해서는 큰 걱정은 아니라 생각합니다
(기회가 나면 어차피 누구든 시도할 것이고 마켓메이킹이 된다는점에서 긍정적 효과도 있습니다)
그러나 블록순서에 영향이 있는게 맞다면 공정성 관련해서 꽤 큰문제라고 생각합니다.
작게는 지금 DEX서비스에서만 이익을 취하고 있지만, 다른 디파이서비스에도 영향을 미칠 가능성이 있기때문입니다.
1개의 좋아요
맞습니다… 아비트리지는 디파이 생태계 아주 중요한 역할을 합니다.
dex별 거래를 활성화 시켜 디파이 서비스에 아주 중요한 역할을 하고 있죠.
아비트레이더가 없다면 각 dex에 나오는 이자가 크게 줄어들거라 생각되네요.
디파이만 아니라 게임파이(P2E), NFT에도 악영향이 발생할수 있을거 생각되네요.
1개의 좋아요
음…
Front-Running을 한다고 가정하기 위한 데이터 셋이 부족해 보이는데
위에 알려주신 주소들이 첫번째 트랜잭션으로 들어가는 블록 범위를 알려주실 수 있나요?
프론트 러닝과는 관계없다고 보시면될 것 같습니다.
매 블록마다 simulation후 Tx를 날리는 구조로 보이는데,
다른건 다 제쳐두고 매번 1개의 Tx를 날리는데 블록의 1번에 담긴다는게 주요 문제라고 봅니다.
프론트러닝이나 아비트라지를 하는건 문제가 아니라봅니다!
매번 컨트랙트를 바꿔가면서하고있어서, 가장 최근주소 는 위 주소 사용중이네요
Fee delegated 된 거의 대부분 Tx가 1등입니다.
약 1년이 지났는데 어떤 이유로 가능했는지 밝혀졌을까요?
아시는 분 계시면 답변 부탁드립니다!