이번 주가 시작되면서 리플 명예 CTO인 David Schwartz는 XRPL 결제 및 제안 교차에 대한 선행 실행 또는 거래 샌드위치 공격 가능성에 대한 우려를 표명했습니다.
Schwartz는 트랜잭션 슬롯을 예약함으로써 이러한 문제를 제거하는 매우 간단한 트랜잭션 예약 방식을 제안했습니다. 거래 예약 체계는 거래가 공개된 후 생성된 후속 거래가 발생하기 전에 거래가 실행되도록 보장합니다.
이는 XRP 커뮤니티의 다양한 부문에서 반응을 불러일으켰으며 일부는 이 계획이 XRP Ledger에 어떻게 작동할 수 있는지 묻습니다.
그러한 사례 중 하나에서 X 사용자는 "트랜잭션이 주문될 때 시간에 따라 정렬되도록 타임 스탬프를 두 번째까지 추가할 수 있는지 물었습니다. 그런 식으로 누군가가 트랜잭션을 제출한 후 적어도 1초가 지난 후 자동으로 첫 번째 트랜잭션 이후에 주문됩니다. "
Ripple소프트웨어 엔지니어인 Mayukha Vadari는 대화에 참여하여 이 질문에 부정적으로 대답했습니다. 트랜잭션은 피어 네트워크를 통해 전파되어야 하기 때문에 서로 다른 노드가 약간 다른 시간에 각 트랜잭션을 수신할 수 있다는 점을 지적했습니다.
Schwartz는 이에 가장 가까운 것이 합의 프로세스의 일부로 검증인이 투표하는 합의 기반 거래 주문이라고 강조했습니다.
거래 순서 문제에 대해 Schwartz는 가능한 시나리오를 설명합니다. 즉, 합의 프로세스의 일부로 이에 대해 투표하는 검증자와의 합의에 의해 결정되는 시나리오입니다.
실제로 할 수 있는 가장 가까운 일은 합의 프로세스의 일부로 거래 순서에 투표하는 검증자와의 합의에 의해 거래 순서를 결정하는 것입니다. 그러나 이것에는 많은 단점이 있습니다. 가장 큰 문제는 속도가 느려진다는 것입니다…
리플 CTO Emeritus는 여기에는 많은 단점이 있다고 지적했습니다. 가장 큰 문제는 합의에 도달하는 비트 수가 증가하기 때문에 합의 프로세스가 크게 느려진다는 것입니다.
Schwartz는 한 가지 옵션을 언급했습니다. 트랜잭션에 시퀀스를 요청하는 플래그를 설정하는 것이지만 추가 비용이 발생한다는 것입니다. 플래그가 설정된 거래는 동일한 원장에서 플래그가 없는 위의 거래를 중계하는 데 우선 순위가 부여되며 순서는 합의에 의해 결정됩니다. 그러나 그는 한 가지 문제점을 발견했습니다. 이는 전방 공격이나 샌드위치 공격을 가능하게 할 수 있다는 것입니다.
슈워츠는 "하지만 그럴 가치가 없다고 생각한다"며 "특히 플래그를 설정하지 않은 거래를 선취하거나 샌드위치하는 것이 더 쉬워지기 때문"이라고 말했다.
원문 제목: Ripple CTO Emeritus Weighs Major XRP Ledger Transaction Change, but Sees Catch
At the week's start, Ripple CTO emeritusDavid Schwartzaddressed concerns about the possibility of front-running or transaction sandwich attacks onXRPLpayments and offer crossing.
Schwartz proposed a fairly simple transaction reservation scheme that would eliminate such concerns by reserving transaction slots.
The transaction reservation scheme will ensure that a transaction executes before any subsequent transactions created after it are disclosed.
This attracted reactions from various quarters of theXRP community, with some asking how the scheme could work for theXRP Ledger.
In one such instance, an X user asked if it will be possible to add a "time stamp down to the second, so that when transactions are ordered they would be ordered by time, that way if someone submitted a transaction after it would be at least a second after and would automatically get ordered after the first one.
".
Ripplesoftware engineer Mayukha Vadari joined the conversation, answering this question in the negative, noting that different nodes may receive each transaction at slightly different times, as transactions have to propagate through the peer network.
Schwartz highlighted that the closest thing to this is consensus-based transaction ordering, with validators voting on it as part of the consensus process.
On the question of transaction ordering, Schwartz describes a likely scenario: one determined by consensus with validators voting on it as part of the consensus process.
About the closest thing to this you could actually do is have transaction ordering determined by consensus with validators voting on transaction ordering as part of the consensus process.
But there are a lot of disadvantages to this.
The big one is that it would slow the….
TheRipple CTO Emeritusnoted that there are a lot of disadvantages to this.
The big one is that it would slow the consensus process significantly because the number of bits on which to reach consensus will increase.
Schwartz mentioned one option: having a flag to request sequencing set on a transaction, but this would cost an extra fee.
Transactions with the flag set would be prioritized for relaying above transactions without the flag in the same ledger, and their ordering would be determined by consensus.
He, however, sees a catch: it might enable front-running or sandwich attacks.
"I don't think it's worth it though, particularly because it makes it easier to front-run or sandwich transactions that don't set the flag,"Schwartzsaid.
