Взаимодействие компонентов
Last updated
Last updated
В предыдущем разделе были представлены компоненты системы. Для каждой ключевой функции CAPE (чеканка, передача, заморозка и т. д.) диаграмма последовательности описывает, как компоненты взаимодействуют друг с другом. Обратите внимание, что хотя некоторые детали были опущены для ясности, приведенные ниже рисунки являются точным представлением того, что на самом деле происходит в развернутой системе.
Если Алиса хочет отчеканить несколько токенов, ей сначала нужно создать транзакцию чеканки (1). Эта транзакция указывает, кто является минтером, кто получит отчеканенные токены, количество отчеканенных токенов и тип актива (обозначаемый как alice_coin ) токенов. Как только транзакция будет создана, кошелек Алисы отправит ее ретранслятору (2) вместе с запиской, содержащей запись актива в зашифрованном виде. Затем (3) ретранслятор возьмет транзакцию и заметку и поместит их в блок CAP (в будущих версиях CAPE ретранслятор будет упаковывать несколько транзакций в блок). Этот блок CAP передается в контракт CAPE (4). Если блок действителен, контракт CAPE выдаст некоторое событие (5), содержащее блок и список дополнительных элементов, которые будут обсуждаться ниже. Пока этот список пуст. Тем временем EQS постоянно отслеживает контракт CAPE на наличие новых событий, когда такое событие генерируется, EQS пересылает его всем подписанным участникам (6,7,8,9). Кошельки при получении нового события блокировки пытаются получить заметки, содержащиеся в блоке, и расшифровать их содержимое (10,11). Если расшифровка прошла успешно, соответствующие записи актива сохраняются локально для дальнейшего использования (12).
Если Алиса хочет передать какие-то активы Бобу, ей сначала нужно получить открытый ключ шифрования, соответствующий адресу Боба (1,2). Этот открытый ключ шифрования потребуется для вычисления памятки получателя, чтобы Боб мог восстановить свои записи об активах после того, как транзакция передачи будет обработана контрактом CAPE. Построение транзакции перевода требует, чтобы Алиса предоставила свой собственный адрес, адрес Боба, тип актива и сумму для перевода (3). Результатом этого вычисления будет транзакция перевода и два служебных записки. Один для Алисы, соответствующий изменению, и один для Боба. Как и в случае с Mint , транзакция CAP и заметки будут отправлены на ретранслятор (4), упакованы в блок (5) и перенаправлены в контракт CAPE (6). После проверки блока генерируется новое событие блока (7), и все подписанные участники уведомляются (8,9,10,11). Алиса и Боб соответственно получают заметки, расшифровывают их (12 или 14) и соответствующим образом обновляют свое локальное состояние (13 или 15). Наконец, аудитор (или наблюдатель) может просматривать некоторые поля транзакции в соответствии с политикой передаваемого актива. Такая информация может храниться локально для дальнейшего анализа (этап 16).
В некоторых ситуациях специальный участник, Морозильщик, может захотеть заморозить некоторые записи актива. Для этого она создаст транзакцию замораживания , указывающую, какая запись актива должна быть заморожена (1). Как описано выше, эта транзакция будет отправлена на ретранслятор (2), который перенаправит ее на контракт CAPE в форме блока (3,4). Как только транзакция подтверждается контрактом CAPE, создается новое событие блока (5), которое пересылается подписавшимся участникам EQS (6,7,8,9). Теперь, если Боб хочет потратить свою запись, создав транзакцию передачи (10,11,12,13), контракт CAPE отклонит ее, так как невозможно создать действительную транзакцию передачи, содержащую некоторые замороженные входные данные (14). Обратите внимание, что в текущей реализации Relayer не проверяет транзакцию.
CAPE позволяет манипулировать не только нативными активами, то есть активами, которые чеканятся внутри системы, но и токенами ERC20. Для этого пользователь (например, Алиса) может спонсировать актив CAPE, который состоит из предоставления сопоставления между токеном ERC20 (например, USDC) и определением типа актива. Это отображение получено и сохранено контрактом CAPE (1,2).
Как только сопоставление определено, любой пользователь, такой как Боб, может преобразовать некоторые токены ERC20 (USDC) в некоторые записи активов, которые можно использовать внутри системы. На практике Боб вносит токены ERC20 и предоставляет соответствующую запись актива для контракта CAPE (3). Контракт CAPE проверит согласованность между передачей токенов ERC20 и записью (в частности, суммы должны совпадать). После успешной проверки контракт CAPE выдаст какое-то событие о новой записи упакованного актива (4), и это событие будет передано EQS (5,6). На данном этапе запись актива еще не доступна для Боба, но помещена в очередь ожидающих депозитов внутри контракта CAPE. Только когда новый блок будет отправлен и успешно проверен (7,8,…,14), Боб сможет сохранить запись своего актива (представляющую несколько токенов ERC20) для дальнейшего использования (15).
В какой-то момент Боб может захотеть обменять свой упакованный актив на токены ERC20. Этот процесс называется распаковкой. Для этого Боб создаст транзакцию записи, которая представляет собой транзакцию передачи упакованной записи актива на некоторый нулевой адрес. Эта транзакция также предоставляет адрес Ethereum, на который отправляются токены ERC20. На диаграмме Боб хочет развернуть записи своих активов, используя адрес Евы в Ethereum, чтобы отправить их Еве (16). Транзакция после отправки на ретранслятор (17) и перенаправления на контракт CAPE (18) инициирует передачу токена ERC20, соответствующего данным записи, на адрес Евы в эфириуме (19).
