Итак, ваша команда закончила alpha-версию вашего блокчейна, и пришло время запускать testnet, а затем и mainnet. У вас настоящий блокчейн, с независимыми участниками, хорошей экономической моделью, безопасностью, вы спроектировали governance и теперь пора бы попробовать все это в деле. В идеальном криптоанархическом мире, вы выкладываете в сеть genesis block, окончательный код ноды и валидаторы сами все запускают, поднимают все вспомогательные сервисы и все случается само собой. Но это в выдуманном мире, а в реальном, команда должна подготовить довольно много вспомогательного софта и различных манипуляций чтобы помочь валидаторам запустить устойчивую сеть. Об этом данная статья.
Рубрика «Governance»
Что такое игра валидаторов или “как запустить proof-of-stake блокчейн”
2019-10-25 в 18:44, admin, рубрики: game of stakes, Governance, Proof-of-stake, блокчейн, децентрализованные сети, информационная безопасность, КриптовалютыУправление API и SOA
2015-04-20 в 8:51, admin, рубрики: .net, api, ASP, C#, Conference, gosharp, Governance, JBORS, JBOWS, rest, sla, Блог компании GeekFamily, принципы проектирования, метки: API, Governance, JBORS, JBOWS, REST, SLA, SOA 
Достижение начального успеха для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) определяется:
- созданием слабосвязанных соединений «потребитель-поставщик»,
- соблюдение принципа разделения ответственностей между потребителем и поставщиком,
- публикация набора повторно используемых, общих сервисов
- и обеспечение того, чтобы потребители приняли и стали использовать сервис.
Множество команд разработчиков создают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).
Простое приложение чаще всего работает с неким сервисом и спагетти-сетью конечных точек, поставщиков данных этого сервиса, которые переплетены связями один-к-одному. Многие команды в этом случае сходятся во мнении что фокус на SOA и REST не то чтобы помогал в решении вопросов гибкости решений. Скорее просто происходит подмена набора IT инструментов, форматов сообщений и протоколов.
Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.
Сервисы, API и архитектура
Когда вы будете решать, что использовать как лучшие практики для сервис-ориентированной архитектуры, определять дизайн RESTful сервисов, когда будете формировать план по управлению ими, четко определите, как ваши сервисы и API вместе будут укладываться в общую архитектурную картину.
Читать полностью »