MPP, Visa, Agents, 0x402, Tempo는 도대체 뭐고, 이 모든 것들이 어떻게 관련되어 있는 거야? @Stripe와 @Tempo가 오늘 MPP와 메인넷을 출시했습니다. 이어서 @Visa는 상담원을 위한 Visa CLI를 발표했습니다. @base는 거의 1년 동안 0x402 오류를 해결해 왔습니다. 이것들이 같은 건가요? 그들 모두 스테이블코인을 사용하고 있나요? 모든 지원자 중에서 단 한 명의 우승자가 나올까요? 이 분야를 이해하는 한 가지 방법은 종종 혼동되는 두 가지 서로 다른 논쟁을 구분하는 것입니다. 하나는 크립토 레일과 카드에 대한 논쟁이고, 다른 하나는 MPP와 0x402에 대한 논쟁입니다. 1. 결제 방식 논쟁: 카드 결제 방식 vs. 암호화폐 결제 방식 이는 보다 친숙한 차원입니다. 궁극적으로 돈을 이동시키는 금융 인프라에 관한 것입니다. 기존 카드 네트워크는 단순하고, 전 세계적이며, 가맹점 생태계에 깊이 통합되어 있기 때문에 여전히 강력한 영향력을 발휘합니다. 소프트웨어 에이전트가 카드 결제를 처리할 수 있도록 프로그래밍 가능한 인터페이스를 제공함으로써 기존 비즈니스 워크플로를 재설계하지 않고도 구매를 자동화할 수 있습니다. 대규모 거래나 간헐적인 거래의 경우, 이러한 모델은 여전히 ​​효율적입니다. 회계 처리가 명확하고, 규정 준수가 기본적으로 보장되며, 거의 모든 곳에서 결제가 가능합니다. 암호화폐 기반 결제 시스템은 기존 방식과는 다른 특성을 제공합니다. 스테이블코인을 사용하면 즉각적인 글로벌 결제, 낮은 수수료, 그리고 에이전트가 직접 관리할 수 있는 프로그래밍 가능한 잔액을 구현할 수 있습니다. 이는 소액 결제, 빈번한 결제, 또는 지속적인 결제가 발생하는 환경에서 특히 중요합니다. 머신 워크로드는 개별 구매보다는 사용량에 따라 계산되는 경우가 많습니다. 이러한 환경에서는 블록체인 기반 시스템을 통해 스트리밍 또는 배치 방식의 소액 결제를 구조적으로 더 쉽게 구현할 수 있습니다. 핵심은 결제 방식 선택이 주로 경제적인 요인에 달려 있다는 점입니다. 개발업체는 지불 빈도, 규모 및 운영 복잡성에 가장 적합한 철도 방식을 선택할 것입니다. 2. 프로토콜 논쟁: 0x402 vs MPP 두 번째 논쟁은 정산 단계 바로 위에서 벌어지고 있습니다. 이는 부동산 중개인이 실제로 지불 의사를 어떻게 표현하는지에 관한 것입니다. 0x402 스타일 흐름과 MPP는 모두 오랫동안 사용되지 않았던 HTTP 402 결제 필요(Payment Required) 시맨틱을 기반으로 합니다. 공통된 아이디어는 결제가 웹의 일반적인 요청-응답 주기의 일부가 되어야 한다는 것입니다. 에이전트가 리소스를 요청하면 서버는 기계 판독 가능한 결제 챌린지를 발행합니다. 에이전트는 권한을 증명하고, 액세스가 허용됩니다. 0x402 구현은 주로 상태 비저장 결제 문제를 해결하는 데 중점을 둡니다. 각 요청에 결제 요구 사항을 포함할 수 있으므로 모델이 단순하고 구성 가능합니다. 이러한 접근 방식은 저비용 실행으로 빈번한 상호 작용을 지원하는 Base와 같은 생태계에서 인기를 얻고 있습니다. MPP는 결제 세션을 통해 보다 체계적인 프레임워크를 제공합니다. 에이전트는 정의된 제약 조건을 사용하여 지출 약정을 생성하고 사용량을 시간에 따라 점진적으로 정산할 수 있습니다. 이는 거래 오버헤드를 줄이고 추론, 데이터 피드 또는 자동화된 워크플로와 같은 지속적인 서비스 소비에 적합합니다. 현재 MPP와 Tempo의 관계는 초기 0x402 배포와 Base의 관계와 유사합니다. 선호하는 실행 환경은 존재하지만, 프로토콜 자체는 단일 체인에 종속되지 않습니다. MPP는 결제 방식에 구애받지 않도록 설계되었으며 스테이블코인, 카드, 은행 시스템, 수탁 시스템 등 다양한 결제 수단에서 작동할 수 있습니다. Stripe 자체의 여러 표준 실험은 장기적인 스택이 멀티 프로토콜 기반이 될 것임을 시사합니다. 두 층을 결합 이러한 차원들을 분리하고 나면, 다양한 방식으로 조합할 수 있다는 것이 분명해집니다. 개발자는 0x402 챌린지를 통해 조정되는 암호화폐 결제를 사용할 수 있습니다. 또 다른 시스템은 스테이블코인 레일을 사용하는 MPP 세션을 활용할 수도 있습니다. 경우에 따라서는 에이전트가 카드 승인이나 오프체인 잔액을 통해 결제하는 동시에 HTTP 네이티브 표준을 사용하여 결제를 조정할 수도 있습니다. 실제로 모든 조합이 똑같이 자연스러운 것은 아닙니다. 빈번한 기기 간 상호작용은 암호화 방식 및 세션 기반 조정과 잘 맞는 경향이 있습니다. 반면, 규모가 크고 일회성으로 이루어지는 구매는 카드 네트워크 및 간소화된 승인 흐름과 잘 맞는 경우가 많습니다. 중요한 점은 생태계가 단일 설계로 수렴하는 것이 아니라 두 가지 방향을 동시에 탐색하고 있다는 것입니다.