Я пытаюсь понять SMART-контракты и хотел бы помочь с моим пониманием. Я думаю, что лучший способ ответить на мои вопросы — это привести примеры сценариев.
Если у меня есть нотариальная служба на блокчейне, у меня будет контракт под названием Notary.sol. Это будет содержать такие данные, как владелец, получатель, документ. После того, как все стороны подписали документ, куда-то отправляется подтверждение. Мой вопрос заключается в том, что каждый раз, когда новый документ нуждается в нотариальном заверении, нужно ли мне снова отправлять новый контракт в блокчейн, чтобы появился новый «экземпляр» с новым состоянием и т. д.?
В дополнение к примеру с нотариусом я хотел бы, чтобы смарт-контракт проверял дополнительные сведения о других сторонах, прежде чем им будет разрешено подписать. Например, проверка их разрешений или даже просто получение их имени. Чтобы сделать это, я должен вызвать другой смарт-контракт как событие, чтобы вернуть результат, прежде чем продолжить с остальной частью контракта?
В сфере здравоохранения есть врачи и пациенты. Например, у врача может быть много пациентов. У пациента может быть лечащий врач. Аналогичные отношения применяются к учителям и ученикам (отношения «многие ко многим»). Это может усложниться с сохранением оценок учащихся. Это кажется более подходящим для управления этим в реляционной базе данных, но блокчейн используется для управления доверием к записи транзакции. В случае врача пациента пример. Я мог бы захотеть заключить контракт на перевод всех пациентов к другому врачу, если их текущий уходит / уходит на пенсию. Для этого требуется, чтобы блокчейн знал, какие пациенты принадлежат врачу. Как я могу контролировать это в блокчейне или контрактах?
Как убедиться, что контракт могут выполнять только определенные пользователи? Будут ли в контракте их адреса, которые мы сможем проверить перед исполнением?
Надеюсь, это понятные вопросы, и я ценю ответы
Спасибо
Вероятно, самым простым (и дешевым) вариантом будет использование одного и того же контракта для всех документов. У вас будет логика в вашем контракте, которая позволит стороне создать документ (возможно, используя хэш документа) и указать стороны, которые должны его подписать.
Любое решение будет работать нормально. Все зависит от вашей архитектуры. Если вы чувствуете, что реализация проще, если вы используете отдельный контракт для управления разрешениями, сделайте это.
Вы правы, думая, что некоторые вещи лучше не использовать в блокчейне и в реляционной базе данных. Во-первых, вы не можете делать сложные запросы к данным дешево (а иногда и вообще). Мой совет: делайте все как можно проще. Одним из примеров структуры данных, которую вы можете использовать для связывания врачей с пациентами, является простая карта адресов пациентов с адресами врачей:
// map of patients to doctors
mapping (address => address) patientsDoctors;
Да, в контракте должен быть указан адрес пользователя, но это не означает, что вы должны знать адрес во время создания контракта. Например, в вашем контракте может быть один admin, назначенный при создании контракта, которому разрешено изменять карту agents. Затем некоторые функции должны будут завершиться ошибкой, если msg.senderони не содержатся в agentsкарте.
Расшифровщик
дальтон_с