Pull и Push архитектура платежей
Фиатная платёжная инфраструктура во многом построена на pull-модели. Когда ты даёшь банку, мерчанту или подписочному сервису реквизиты своей карты, ты предоставляешь им право списывать с тебя деньги. Безакцептные и рекуррентные платежи как пример: кто-то другой инициирует движение твоих денег. Исторически это было удобным решением. На практике pull-модель стала архитектурной дырой и вектором массового мошенничества: скомпрометированные реквизиты позволяют списывать средства без ведома владельца, а оспаривание транзакций превращается в бюрократический ад.
Блокчейн — push-only по дизайну. Никто не может списать с чужого кошелька средства без предварительно подписанного владельцем разрешения. Каждый платёж есть акт воли отправителя. Это фундаментально другая архитектура: не «я разрешаю тебе брать», а «я отправляю тебе». Со временем стали появляться и набирать популярность всякие аналоги: переводы по QR, СБП и т.п.
Часто критикуют отсутствие нативных рекуррентных платежей в блокчейне. Но подписочная модель в фиате порождает свои злоупотребления. Dark UX паттерны стали индустриальным стандартом: подписка производится за один клик, а отписка уже через десять экранов, звонок в поддержку и ожидание. Целые бизнесы живут на пользователях, которые забыли отписаться. Pull-модель создаёт для этого идеальные условия, при которых деньги списываются по умолчанию, а бездействие работает на владельцев сервиса.
Push-модель возвращает контроль отправителю: для проведения платежа нужно внимание и мотивация, а не наоборот. Однако, при здоровой потребности в регулярных платежах типа донатов в открытые проекты, периодические переводы действительно используемым сервисам инфраструктура уже появляется. Например, Kalatori решает задачу приёма платежей в интернете удобно для пользователя. Являются открытым решением для обработки блокчейн-платежей в Polkadot/EVM экосистемах. Регулярные платежи ончейн тоже есть. Это не замена подписок — это альтернативная архитектура, где рекуррентность — осознанное действие плательщика, а не пассивное разрешение списывать.
Для заинтересованных:
• Обсуждение проекта в Базовом Блоке
• Питч-дек
Post #606
284
Foxcool (darkfox.info) Реализация механизмов доверия on-chain Эластичная эмиссия требует Identity, Intent, Recourse. Trustless-системы от них отказываются. Но это ложная дихотомия — если рассматривать trustless как бинарный переключатель. Виталик показал, что trustless — это спектр.…