Техническая реализация безопасной системы сделок через модель эскроу (не гаранты, а математика)

[artptr86]

Никто не может украсть деньги, потому что реализуются следующие сценарии:

Арбитр хочет забрать деньги — Нужен ключ покупателя ИЛИ продавца

Что мешает продавцу вступить в сговор с арбитром, перевести ему деньги, а потом поделить их?

[kirill-shtepa]

Справедливое замечание. Мультисиг 2-из-3 защищает от действий одной стороны, но не от сговора двух - это ограничение модели. Сейчас арбитр = сервис, и защита здесь репутационная + экономическая (как у банковского эскроу). В планах - случайное назначение арбитров из пула, что делает сговор непрактичным. Спасибо за вопрос, добавлю этот момент в документацию.

[vryzhak]

Бот крутой. Приватные ключи продавца и покупателя бэкенд все равно видит, так что в момент какого-то security breach все может пойти не так. Тут скорее нужно смотреть в сторону threshold signatures, если задача сделать true decentralized escrow.

[kirill-shtepa]

Полностью согласен. Backend действительно видит ключи в двух точках: генерация и подпись. Для MVP это осознанный компромисс - но true decentralized escrow требует именно TSS или MPC. Смотрим в эту сторону, пока упираемся в отсутствие production-ready библиотек для TRON. Если есть опыт с TSS на EVM-совместимых сетях - буду рад обсудить)