Зоряний протокол у майстра · зоряний зірковий протокол · GitHub

Пропозиції, що підкріплюються активами, - це пропозиція щодо вирішення проблеми, через яку пропозиції у книзі можуть не виконуватися.

зоряний

Пропозиції з підтримкою активів - це пропозиція щодо вирішення проблеми, пов’язаної з тим, що на одному рахунку можуть бути зобов’язання у формі пропозицій у книзі, що перевищує активи рахунку. Коли це трапляється, пропозиції в книзі можуть не виконуватися, в тому сенсі, що не існує жодної пропозиції перетину, яка обміняється на всю суму пропозиції. Пропозиції в книзі, які не виконуються, створюють помилкове відчуття ліквідності.

Ми скажемо, що пропозиція є "негайно виконуваною в повному обсязі" (коротше IEIF), якщо б, якщо її перекреслила гіпотетична пропозиція без обмежень щодо суми купленого чи проданого, обмінялася б вся сума продажу активу. Бажано, щоб усі пропозиції були IEIF, оскільки це дозволяє користувачам легко оцінити обсяг наявної ліквідності.

Протокол вимагає, щоб при створенні кожна пропозиція відповідала наступним двом умовам:

  • Пропонована до продажу сума не перевищує наявного залишку активу, що продається
  • Сума, запропонована для придбання (обчислена неявно), не перевищує наявного ліміту купівельного активу

Зараз ми продемонструємо, що цих умов недостатньо, щоб гарантувати, що пропозиція є IEIF. Припустимо, що рахунок створює пропозицію в розмірі IEIF із сумою продажу, рівною наявному залишку активу, що продається. Потім рахунок створює другу пропозицію з гіршою ціною, але інакше ідентичну першій. Хоча кожна пропозиція індивідуально задовольняє вищезазначені вимоги, друга пропозиція не є IEIF. Припустимо, що другу пропозицію перетнула гіпотетична пропозиція без обмежень. Ця пропозиція перетину спочатку перетинала б першу пропозицію, яка не залишає залишку на балансі для активу, що продається. Коли друга пропозиція перетинається, ніякі активи не можуть бути обмінені.

Аналогічно наведеному вище прикладу, можна створити кілька пропозицій, які індивідуально відповідають вимогам, але перевищують доступний ліміт, якщо розглядати їх у сукупності. Припустимо, що пропозиція створює пропозицію, яка є IEIF, із сумою купівлі, що дорівнює доступному ліміту купівельного активу. Потім рахунок створює другу пропозицію з гіршою ціною, але інакше ідентичну першій. Хоча кожна пропозиція індивідуально задовольняє вищезазначені вимоги, друга пропозиція не є IEIF. Припустимо, що другу пропозицію перетнула гіпотетична пропозиція без обмежень. Ця пропозиція про перехід спочатку перетинала б першу пропозицію, яка не залишає обмежень для купівлі активу. Коли друга пропозиція перетинається, ніякі активи не можуть бути обмінені.

Ця пропозиція потребуватиме змін XDR для AccountEntry та TrustLineEntry, а також оновлення схем для таблиць облікових записів та довіри. Оновлений XDR:

SQL, необхідний для оновлення схеми:

Також необхідно додати код результату операції ACCOUNT_MERGE_DEST_FULL:

Метою пропозиції, що підтримується активами, є підтримка незмінності того, що кожна пропозиція є IEIF. Ми починаємо з обговорення того, що може призвести до того, що пропозиції більше не будуть IEIF:

З цього аналізу стає зрозуміло, що будь-яка пропозиція, яка намагається змінити або видалити пропозиції, які більше не є IEIF, потребуватиме ведення книги пропозицій після збору плати та після кожної операції. Це було б і складно, і неефективно. Натомість ми продовжуємо пропозицію, яка модифікує операції таким чином, що вони гарантують, що пропозиції залишатимуться IEIF. Для досягнення цього ми спочатку визначаємо нові величини, які є похідними даними в книзі:

  • account.sellingLiaries
    • Для рахунку А: сума власного активу, що пропонується до продажу, сукупна за всіма пропозиціями, що належать А
  • account.buyingLiaries
    • Для рахунку А: сума власного активу, який пропонується придбати, сукупна за всіма пропозиціями, що належать А