리플 CTO 명예 David Schwartz는 최근 X 게시물에서 XRP Ledger 지불 및 제안 교차에 대한 선행 실행 또는 거래 샌드위치 공격 가능성에 대한 우려를 강조했습니다.
XRP Ledger 기반 마켓플레이스인 XRPresso의 X 핸들은 게시물을 통해 이러한 우려를 표명하면서 XRP Ledger에서 일반 사용자에게 불이익을 주는 "심각한 전면 실행 문제"가 계속되고 있음을 지적했습니다.
검증인과 잘 연결된 노드는 원장이 닫히기 전에 사전 검증 대기열에서 거래를 확인하고 보류 중인 거래를 신속하게 분석하여 선행 거래 또는 샌드위치 거래가 수익성이 있는지 판단할 수 있습니다. 그런 다음 그들은 해당 원장의 정식 순서에 따라 자신의 위치를 조작하려고 자신의 거래를 스팸합니다.
XRPL 문서에 따르면 거래 순서는 선행 실행을 방지하기 위해 예측할 수 없도록 설계되었습니다. 그러나 연구와 실제 관찰에 따르면 이러한 보호만으로는 충분하지 않은 것으로 나타났습니다. 이 메커니즘은 특히 보류 중인 트랜잭션에 대해 더 빠르거나 권한 있는 가시성을 가진 사람들에 의해 여전히 악용될 수 있습니다.
이는 트랜잭션 대기열 가시성과 잠재적인 개인 정보 보호 개선에 대한 논의를 통해 수년 동안 커뮤니티에서 알려진 주제였습니다.
Schwartz는 프론트 러닝 또는 샌드위치 공격에 대한 우려를 제거할 수 있는 매우 간단한 체계를 제안합니다. 즉, 트랜잭션이 공개된 후 생성되기 전에 트랜잭션이 실행되도록 보장하는 트랜잭션 예약 체계입니다.
XRPL 지불 및 제안 교차에 대한 선행 실행 또는 거래 샌드위치 공격 가능성에 대한 우려가 제기되었습니다. 앞서 설명드린 이유로 인해 저는 이 문제에 대해 그다지 걱정하지 않습니다. 하지만 저는…https: //t를 제거할 매우 간단한 계획에 대한 제안을 가지고 있습니다. co/lnh Tv1bhBK.
여기에서는 원장 시퀀스 번호와 트랜잭션 ID 배열을 포함하는 새로운 원장 개체인 "Reserved Txns"가 제안됩니다. 고정된 문자열의 해시와 원장 시퀀스 번호로 구성된 인덱스에 저장됩니다.
또한 원장 번호와 트랜잭션 ID를 매개변수로 사용하는 트랜잭션의 실행 슬롯을 예약하기 위해 새로운 트랜잭션인 "Txn Reserve"를 제안합니다.
이는 일반 거래 수수료의 최소 두 배에 해당하는 수수료를 지불하고 일반적인 거래 실행 요구 사항을 모두 충족하면 성공합니다. 또한, 거래에 명시된 원장 순번은 현재 원장 순번보다 커야 하며, 그보다 큰 16개 원장을 초과할 수 없습니다.
지정된 원장 시퀀스 번호에 대한 예약된 Txns 개체가 존재하지 않거나, 존재하는 경우 32개 미만의 트랜잭션 ID를 포함하고 지정된 트랜잭션 ID를 포함하지 않아야 합니다.
원문 제목: XRPL Security Upgrade? Ripple CTO Emeritus Pitches Anti Front-Running Plan
Ripple CTO EmeritusDavid Schwartz highlighted concerns about the possibility of front-running or transaction sandwich attacks on XRP Ledger payments and offer crossing in a recent X post.
The X handle ofXRP Ledger-based marketplace XRPresso revealed these concerns in a post, noting that a "serious front-running issue" continues on the XRP Ledger that disadvantages regular users.
Validators and well-connected nodes can view transactions in the pre-validation queue before a ledger closes and quickly analyze a pending trade to determine if front-running or sandwiching it is profitable.
They then spam their own transactions to try to game their position in the canonical order for that ledger.
XRPLdocumentation indicates that the order of transactions is designed to be unpredictable to discourage front-running.
However, research and real-world observation have shown that this protection is not sufficient.
The mechanism can still be exploited, especially by those with faster or privileged visibility into pending transactions.
This has been a known topic in the community for years, with discussions around transaction queue visibility and potential privacy improvements.
Schwartzproposes a fairly simple scheme that might eliminate concerns about front-running or sandwich attacks: a transaction reservation scheme to ensure that a transaction executes before any transaction created after it was disclosed.
Concerns have been raised about the possibility of front running or transaction sandwich attacks on XRPL payments and offer crossing.
For the reasons I've explained, I'm not that concerned about this issue.
But I have a proposal for a fairly simple scheme that would eliminate…https://t.
co/lnhTv1bhBK.
Here, a new ledger object is proposed, "ReservedTxns," which contains a ledger sequence number and an array of transaction IDs.
It is stored at an index that is formed from a hash of a fixed string and the ledger sequence number.
In addition, a new transaction is proposed, "TxnReserve," to reserve an execution slot for a transaction that takes a ledger number and transaction ID as parameters.
This succeeds if it pays a fee of at least twice the normal transaction fee and meets all the normal transaction execution requirements.
Also, the ledger sequence number specified in the transaction must be greater than the current ledger sequence number and not more than 16 ledgers greater than it.
The ReservedTxns object for the specified ledger sequence number either does not exist, or, if it exists, must contain fewer than 32 transaction IDs and not include the specified transaction ID.
