Логика такая
1. Криптовалюты нужны чтобы были майнеры
2. Майнеры нужны чтобы реализовать PoW
3 PoW нужен для достижения консенсуса и масштабирования сети на тысячи узлов
Альтернатива это BFT алгоритмы, но у них есть проблемы с масштабируемостью, там иногда возникает n^2 запросов для подтверждения операции (n — число узлов).
Вот владею я блокчейном, и DLT Trust присылает мне хеш и предлагает этот хеш записать. Видимо мне этот хеш нужен для принятия каких-то очень важных решений, иначе я бы с DLT Trust не связывался. Но вот проблема — у меня нет никаких гарантий, что присланный хеш не является попыткой ввести меня в заблуждение. Если я стану сам проверять хеши, то мне не нужен DLT Trust, если не стану, то у меня нет никаких гарантий, кроме утверждения DLT Trust о том, что все ок.
Повторю, DLT Trust никоим образом не проверяет корректность вычисления хэшей очередных блоков ни в одном из блокчейнов, которые обслуживает. Его первая функциональная задача: обеспечить взаимный обмен хешей. Ответственность за корректность присылаемых хэшей лежит блокчейне.
А что если злобный хакер взломал DLT Trust и может по своему усмотрению посылать кому-надо какие угодно хеши?
Доверие к кому-нибудь или к чему-нибудь в подавляющем большинстве случаев обычно формируется в два этапа. Априори некто считает DLT Trust достойным доверия. Свое мнение он может формировать за счет косвенных факторов, например, отзывы знакомых.
Блокчейн совершает революцию в финансах как раз потому, что убирает «доверенных» участников и связанные с ними процессы с рынка. Вместе с этим исчезнут мириады посредников и регуляторов, которые затрудняют сделки и увеличивают стоимость. Примеры:
— Центробанки;
— Депозитарии, хранящие информацию о ценных бумагах;
— Биржи, гарантирующие исполнение обязательств;
— SWIFT, VISA и прочие
— Escrow сервисы
— и т.д.
Я не берусь ничего утверждать, но с моей колокольни кажется, что введение механизма вроде DLT Trust это шаг назад. Неизбежно затем индустрии понадобится специальный регулятор, который будет следить за тем, чтобы организации подобные DLT Trust не обманывали своих клиентов и вели себя «правильно» и мы вернемся к тому, с чего начинали.
Любой легитимный пользователь, в том числе владелец частного блокчейна, имеет возможность перепроверить всю информацию, касающуюся его блокчейна.
Если я технически могу это сделать, то смысл мне работать с DLT Trust?
Я думаю, что предлагаемый механизм может быть полезен в виде open source библиотеки, которую организации могут использовать по своему усмотрению. DLT Trust как организация вызывает сомнения.
Если мы говорим о частном блокчейне (permissioned blockhain), то в нем должны участвовать только компоненты, которым можно доверять. Если в схему добавить DLT Trust, то нужно доверять DLT Trust, потому что от него приходят хеши, которые надо записать в свой блокчейн.
Важно помнить, сам DLT Trust выступает как посредник, что вы прислали, то он и растиражировал.
Это вы утверждаете, но почему я должен этому доверять?
А что делать с форками цепочки блоков? Совершенно нормально когда в сети есть несколько версий цепочки, различающиеся последними n блоками. В какой-то момент консенсус выберет одну из них, а остальные исчезнут.
То есть в момент времени T, может выясниться, что в T-2 существовало две версии блокчейна Евы (и это нормально) и «выиграла» не та, что была послана в DLT Trust.
1. Как DLT Trust обновит другие блокчейны?
2. Как DLT Trust отличит ситуация форка сети от злонамеренный действия Евы?
Проблема не в том, что дядя Боб и Фаулер антинаучные, проблема в том, что в области проектирования софта вообще ничего научного нет. Это черная магия, что-то происходит в голове проектировщика и он говорит — тут будет «фабрика». Оптимальность этого решения оценить нельзя. Показать, что это решение лучше чем другое, тоже затруднительно.
Как следствие применимость идей дяди Боба и Фаулера к конкретной системе оценить не получится. Результаты будут любыми, иногда хорошими и тогда авторов будут хвалить, иногда плохими и тогда будут ругать себя.
Мне больше нравится точка зрения на FP vs OOP описанная в SICP, где OOP рассматривается как способ достичь модульности путем сокрытия состояния. Того же можно добиться и в FP, например, в Haskell можно сделать что-то вроде
class MyClass state where
myMethod :: (MyClass state) => state -> state
В этом случае разница между OOP и FP заключается только в неизменяемых данных. А если вспомнить OCaml, который функциональный, но данные в нем менять можно, то вопрос о OOP vs FP как-то вообще теряет смысл.
Спасибо больше за подробно расписанные кейсы, этого как воздух не хватает. Все почему-то учатся проектировать на примерах уровня Hello World, а потом удивляется, что получается «лапша».
Я в итоге пришел к точно такой же схеме разбиения GUI приложений. Я рассуждал как-то так:
1. Пользователь, как правило, хочет запустить какую-нибудь «сложную функцию», с большим числом параметров.
2. Но при этом у него есть клавиатура и мышь/пальцы, то есть «за раз» много информации он ввести не может.
3. Значит надо иметь слой в котором кусочки информации будут накапливаться и агрегироваться. Это слой Редактирования у вас и слой View Model у меня.
4. Когда информации достаточно, надо запустить «сложную функцию». Из соображений повторного использования эту «сложную функцию» стоит определить в какой-нибудь сервис.
В итоге путь данных от пользователя в систему и назад выглядит аналогично вашей пятиуровневой модели
1. Вид
2. View Model, слой редактирования и накопления данных от пользователя
3. Сервисы — ради выполнения функции какого-то сервиса пользователь и использует приложение.
4. Модель данных — структуры данных, которые легко сохранить/загрузить и с которые работает сервис. Чаще всего они еще торчат наружу из сервисов.
Инфраструктура — она как-бы сбоку получается, потому что WPF это инфраструктура, но для вида, а LINQ это тоже инфраструктура, но уже скорее для сервисов/модели.
Я объясняю наличие этих 5 слоев тем, что пользователь использует конкретные устройства ввода, а слои это уже следствие. А вот API приложения уже другие, там «ввод» это JSON/XML поэтому слоя редактирования уже не нужно.
Вопрос который меня мучает последнее время — как найти оптимальное разбиение системы на слои в заданной ситуации. Или аналогично — как показать, что разбиение на эти 5 слоев является в некотором смысле оптимальным?
SRP более вреден чем полезен так как определения "ответственности" нет. Изменение ОС это причина для изменения? А смена архитектуры процессора? Что если прямоугольники нужны не с double, а int внутри для ускорения рассчетов? А если мы хотим SIMD? И так далее и тому подобное.
Из всего SOLID только принцип подстановки Барбары Лисков заслуживает внимания, так как у него имеется внятная формулировка. Остальное полезно для ознакомления, применение на практике наталкивается на произвол из-за размытых формулировок.
Как уже верно отметили плюс в общем коде, общим получается где-то 30% кода. Лично для меня еще очень важный плюс — можно внедрить в команде один подход к разработке.
Пример — все View Model сделаны в общем коде, в итоге контроллеры (в iOS) и фрагменты (в Android) получаются практически одинаковыми, так как основаны на одном API.
Справедливости ради хочу отметить, что Xamarin прослойка очень тонкая. Ему от .NET достался p/Invoke, то есть любые C библиотеки подключаются влет. Там также есть неплохой набор инструментов для работы с ObjC и Java кодом.
Вот Xamarin.Forms это реально уже «толстая» прослойка, аналогично React.Native и Appcelerator Titanium.
Все компоненты (PCA, деревья, нейронки и прочеее) уже есть готовые, например в numpy/scipy. Самого алгоритма, в смысле последовательности шагов и конкретных настроек, пока конечно нет, только общие идеи. Алгоритм может появиться только после работы с реальными данными. Не глядя на них можно бесконечно теоретизировать, что то, или иное решение будет работать или нет.
Вопросы о данных
— А они есть в наличии?
— Данные размечены? Например данные о продавце и флажок «хороший/плохой».
— Насколько данные зашумлены? Пропуски значений, ошибки ввода, bias оценок от разных людей (как в фильмах, кто-то всегда ставит хорошо, а у кого-то 3 звезды == 5 звезд)
В этом и состоит задача — отыскать такую метрику, которая бы хорошо разделяла «правильных» и «неправильных» менеджеров. Кстати, может оказаться, что одной метрики мало и в разных частях пространства лучше работают разные метрики (это будет значит, что имеем дело с многообразием менеджеров)
В принципе так и есть. PCA, например, часто используется чтобы выяснить какие параметры важные, а какие нет. В этом, как правило, основная загвоздка, потому что если заранее знать, что «менеджера можно описать заказами и отказами», то задача можно сказать уже решена.
Положим наш менеджер это n-мерный вектор, а мы хотим рассчитать какую-то характеристику, например «F(менеджер) = {плохой, хороший}». Еще предположим, что в данном векторе есть вся необходимая информация для рассвета нашей характеристики. Эта характеристика, в некоторой окрестности, приближается линейной комбинацией координат вектора-менеджера. Далее разбиваем все пространство на участки где лучше работает те или иные коэффициенты и вуаля.
Возможные проблемы
— что-то важное не попало в вектор менеджера (так скорее всего и будет если выбирать важные характеристики «на глазок»)
— может случится, что линейная комбинация приближает менеджера хорошо только на очень небольшом участке
Но хочется попробовать сделать схему, при которой будет сформулирован алгоритм который позволит выявить значимые параметры (или определить, что таких нет), и далее найти метод нахождения «подозреваемых» которые чем-то отличаются.
Все сильно зависит от того какие у вас данные. Мне, почему-то, в голову сразу приходит PCA. Может сработать если деятельность пользователей можно представить в виде числовых характеристик. Если повезет и пользователи хорошо приближаются линейной моделью, то отклонение от среднего и будет мерой необычности. Если нет, то можно пробовать модель усложнять, добавлять нелинейности и тд.
Какие методы тут использовать — вопрос к специалистам по ML, матстатистике и прочим нейросеткам.
Думаю вам надо пробовать разные методы и смотреть, что работает лучше. Все от данных зависит в конце концов, может даже выяснится, что на данных от разных организаций работают разные методы. Если бы меня попросили что-то подобное исследовать, я бы начал с PCA, затем деревья решений, затем нейронки.
1. Криптовалюты нужны чтобы были майнеры
2. Майнеры нужны чтобы реализовать PoW
3 PoW нужен для достижения консенсуса и масштабирования сети на тысячи узлов
Альтернатива это BFT алгоритмы, но у них есть проблемы с масштабируемостью, там иногда возникает n^2 запросов для подтверждения операции (n — число узлов).
А что если злобный хакер взломал DLT Trust и может по своему усмотрению посылать кому-надо какие угодно хеши?
Блокчейн совершает революцию в финансах как раз потому, что убирает «доверенных» участников и связанные с ними процессы с рынка. Вместе с этим исчезнут мириады посредников и регуляторов, которые затрудняют сделки и увеличивают стоимость. Примеры:
— Центробанки;
— Депозитарии, хранящие информацию о ценных бумагах;
— Биржи, гарантирующие исполнение обязательств;
— SWIFT, VISA и прочие
— Escrow сервисы
— и т.д.
Я не берусь ничего утверждать, но с моей колокольни кажется, что введение механизма вроде DLT Trust это шаг назад. Неизбежно затем индустрии понадобится специальный регулятор, который будет следить за тем, чтобы организации подобные DLT Trust не обманывали своих клиентов и вели себя «правильно» и мы вернемся к тому, с чего начинали.
Если я технически могу это сделать, то смысл мне работать с DLT Trust?
Я думаю, что предлагаемый механизм может быть полезен в виде open source библиотеки, которую организации могут использовать по своему усмотрению. DLT Trust как организация вызывает сомнения.
Это вы утверждаете, но почему я должен этому доверять?
То есть в момент времени T, может выясниться, что в T-2 существовало две версии блокчейна Евы (и это нормально) и «выиграла» не та, что была послана в DLT Trust.
1. Как DLT Trust обновит другие блокчейны?
2. Как DLT Trust отличит ситуация форка сети от злонамеренный действия Евы?
Как следствие применимость идей дяди Боба и Фаулера к конкретной системе оценить не получится. Результаты будут любыми, иногда хорошими и тогда авторов будут хвалить, иногда плохими и тогда будут ругать себя.
В этом случае разница между OOP и FP заключается только в неизменяемых данных. А если вспомнить OCaml, который функциональный, но данные в нем менять можно, то вопрос о OOP vs FP как-то вообще теряет смысл.
Я в итоге пришел к точно такой же схеме разбиения GUI приложений. Я рассуждал как-то так:
1. Пользователь, как правило, хочет запустить какую-нибудь «сложную функцию», с большим числом параметров.
2. Но при этом у него есть клавиатура и мышь/пальцы, то есть «за раз» много информации он ввести не может.
3. Значит надо иметь слой в котором кусочки информации будут накапливаться и агрегироваться. Это слой Редактирования у вас и слой View Model у меня.
4. Когда информации достаточно, надо запустить «сложную функцию». Из соображений повторного использования эту «сложную функцию» стоит определить в какой-нибудь сервис.
В итоге путь данных от пользователя в систему и назад выглядит аналогично вашей пятиуровневой модели
1. Вид
2. View Model, слой редактирования и накопления данных от пользователя
3. Сервисы — ради выполнения функции какого-то сервиса пользователь и использует приложение.
4. Модель данных — структуры данных, которые легко сохранить/загрузить и с которые работает сервис. Чаще всего они еще торчат наружу из сервисов.
Инфраструктура — она как-бы сбоку получается, потому что WPF это инфраструктура, но для вида, а LINQ это тоже инфраструктура, но уже скорее для сервисов/модели.
Я объясняю наличие этих 5 слоев тем, что пользователь использует конкретные устройства ввода, а слои это уже следствие. А вот API приложения уже другие, там «ввод» это JSON/XML поэтому слоя редактирования уже не нужно.
Вопрос который меня мучает последнее время — как найти оптимальное разбиение системы на слои в заданной ситуации. Или аналогично — как показать, что разбиение на эти 5 слоев является в некотором смысле оптимальным?
SRP более вреден чем полезен так как определения "ответственности" нет. Изменение ОС это причина для изменения? А смена архитектуры процессора? Что если прямоугольники нужны не с double, а int внутри для ускорения рассчетов? А если мы хотим SIMD? И так далее и тому подобное.
Из всего SOLID только принцип подстановки Барбары Лисков заслуживает внимания, так как у него имеется внятная формулировка. Остальное полезно для ознакомления, применение на практике наталкивается на произвол из-за размытых формулировок.
Пример — все View Model сделаны в общем коде, в итоге контроллеры (в iOS) и фрагменты (в Android) получаются практически одинаковыми, так как основаны на одном API.
Вот Xamarin.Forms это реально уже «толстая» прослойка, аналогично React.Native и Appcelerator Titanium.
Вопросы о данных
— А они есть в наличии?
— Данные размечены? Например данные о продавце и флажок «хороший/плохой».
— Насколько данные зашумлены? Пропуски значений, ошибки ввода, bias оценок от разных людей (как в фильмах, кто-то всегда ставит хорошо, а у кого-то 3 звезды == 5 звезд)
Положим наш менеджер это n-мерный вектор, а мы хотим рассчитать какую-то характеристику, например «F(менеджер) = {плохой, хороший}». Еще предположим, что в данном векторе есть вся необходимая информация для рассвета нашей характеристики. Эта характеристика, в некоторой окрестности, приближается линейной комбинацией координат вектора-менеджера. Далее разбиваем все пространство на участки где лучше работает те или иные коэффициенты и вуаля.
Возможные проблемы
— что-то важное не попало в вектор менеджера (так скорее всего и будет если выбирать важные характеристики «на глазок»)
— может случится, что линейная комбинация приближает менеджера хорошо только на очень небольшом участке
Все сильно зависит от того какие у вас данные. Мне, почему-то, в голову сразу приходит PCA. Может сработать если деятельность пользователей можно представить в виде числовых характеристик. Если повезет и пользователи хорошо приближаются линейной моделью, то отклонение от среднего и будет мерой необычности. Если нет, то можно пробовать модель усложнять, добавлять нелинейности и тд.
Думаю вам надо пробовать разные методы и смотреть, что работает лучше. Все от данных зависит в конце концов, может даже выяснится, что на данных от разных организаций работают разные методы. Если бы меня попросили что-то подобное исследовать, я бы начал с PCA, затем деревья решений, затем нейронки.