Правила вне цепочки и правила в цепочке при разработке DAO

Представьте себе такой DAO, где есть два актора:

  • Business
  • Partners

Что businessможно сделать:

  • Выпустите certificateto partners, который использует определенную нестандартную логику для оценки характеристик partners,
  • Рекламируйте все partnersдоступные JobPostиз business, JobPostможет потребоваться 1 или несколько partnersдля заполнения.

Чтобы заполнить JobPost:

  • Либо parterможно подать заявку на торги с конкурентоспособной ставкой,
  • Или busienssможет активно предлагать/искать партнера.

После JobPostзаполнения WorkContractподписывается a, в котором определенное количество токенов заблокировано и может быть освобождено, partnersкогда оно запускается businessили истекает по тайм-ауту (во время блокировки).

Философский вопрос заключается в том, должно ли решение о заполнении, JobPostсделанное вне сети, сущностью представлять (владея закрытым ключом) business, или сами правила заполнения должны быть частью самого оригинала JobPost.

Технически мы можем сделать и то, и другое. Но если мы используем блокчейн, то в какой степени мы хотим использовать блокчейн — это еще один способ обобщить вопрос.

Надеюсь вопрос понятный!

Ответы (1)

Я думаю, вы тщательно определяете бизнес-правила, которые хотите применять. Сертификаты в основном касаются процесса адаптации с некоторым внешним контролем.

Вы можете сделать так, чтобы партнеры были обязаны принимать заявки в соответствии с книгой заказов на нормализованные товары, или вы можете сделать так, чтобы партнеры сами выбирали, кого они хотят нанять. Вы даже можете захотеть поддерживать оба варианта с каким-либо типом ордера.

Если решение о найме не связано с последующим шагом с логикой в ​​​​цепочке (например, доставкой и расчетом по оплате), неясно, что решение о найме вообще должно быть записано в цепочке. Вы можете обнаружить, что большая часть этого может быть обработана вне сети, а смарт-контракт обеспечивает гарантию этого сертификата (онбординг). https://medium.com/solidified/the-joy-of-minimalism-in-smart-contract-design-b67fb4073422

Надеюсь, поможет.

Спасибо вам за ваш быстрый ответ! Я добавил редактирование, в котором подчеркивается, что это включает в себя подписание рабочего контракта, который включает передачу токена.
Я думаю, вы справитесь, если будете думать в соответствии с предложенным деловым соглашением. В основном речь идет о том, что больше подходит для вашего случая: автоматическое сопоставление порядков или добровольное объединение. Вы можете обнаружить, что блокчейн лучше всего использовать для установления доверия и устранения неопределенности, но не обязательно для принуждения людей к ассоциации.