Документ содержит сравнительный анализ различных блокчейн-систем, включая архитектуры, алгоритмы консенсуса и модели транзакций. Он также охватывает историю проекта Scorex, проблематику двойных трат и возможные улучшения в области масштабируемости и приватности. Практическая часть включает в себя примеры реализации API для работы с активами в блокчейне.

1. Сравнение блокчейн систем
Дмитрий Мешков
IOHK | SCOREX

2. Structure
1. Введение
2. Дизайн криптовалют
3. Алгоритмы консенсуса
4. Транзакционные модели
5. Возможные улучшения
6. Практическая часть

3. Введение

4. Scorex history
● Появление проекта Scorex (Jan 2015)
● Scorex стал частью IOHK (Nov 2015)
● Победа на Московском хакатоне (Nov 2015)
● Запуск Waves (May 2016)
● Scorex 2 (Nov 2016)

5. Why?

6. Governance
● Код – это закон
● Программисты обладают правом писать закон?
● Можно не принимать изменения, которые внесли
программисты (Ethereum classic)
● Голосования майнеров (почему майнеров?)

7. Problematics
● Double spending
● Alice → Bob, Alice → Charlie.
● Кто получит монету?

8. Дизайн криптовалют

9. Properties
● Consistency – вероятность иметь разные префиксы
отбросив последние k блоков экспоненциально
убывает с k
● Chain quality – участник, обладающий x%
голосующей мощности создаст не больше
ax% блоков
● Chain growth – блокчейн растет со временем
● (S)UF-CMA – только владелец приватного ключа
может создать валидную подпись данных

10. Blockchain
● Последовательность блоков
● Дерево блоков
Block 1 Block NGenesis Block N-2 Block N-1 Block NBlock N-3
Block 1 Block NGenesis Block 3 Block 6 Block 9Block 2
Block 4 Block 7
Block 5 Block NBlock 8

11. Minimal state
Может:
● Проверить, что транзакция валидна
● Применить транзакцию к стейту если да
● Одинаковая последовательность блоков
должна приводить к одинаковому стейту

12. Full node view
● Blockchain (blocktree)
● Minimal state
● UTX pool
● Vault

13. p2p: eclipse attacks
● Bitcoin: http://ia.cr/2015/263
● Ethereum: https://goo.gl/mQv58v

14. p2p: throughput
● “On Scaling Decentralized Blockchains”
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf

15. p2p: throughput
● Block size/ X% effective throughput < block interval
● Для сети биткоин (~4000 нод)
● Для маленьких блоков превалирует latency,
минимальное время между блоками для X90% - 12
секунд.
● Для 10 мин. размер блока < 4 Мб для X90% и 36
Мб. для X50%

16. Алгоритмы консенсуса

17. Consensus
● Определяет последовательность блоков,
которы будут применяться к minimal state

18. Consensus: Proof-of-Work

19. Consensus: Proof-of-Work
● Вероятность создать блок пропорциональна
вычислительной мощности
● One-CPU-one-vote
● Распределенный timestamp
● Difficulty recalculation
● Чтобы изменить блок, нужно проделать
работу по созданию всех блоков после него
● Безопасен
● Сжигает ресурсы
● Полезный PoW: primecoin, permacoin

20. Consensus: Proof-of-Stake
● Вероятность создать блок ~ балансу
● Не сжигаются ресурсы
● Подразумевает timestamp
● Нет случайности => griding attacks
● Дешево создавать блоки => History attack
● Nothing-at-stake attack
● Bribe attack

21. Consensus
● Proof-of-Work
● Proof-of-Stake
● Proof-of-Burn
● Proof-of-Space
● Proof-of-Retrievability
● ….
● Hybrid

22. Транзакционные модели

23. Transactional layer: boxes
Bitcoin

24. Transactional layer: boxes
● Minimal state - набор закрытых коробок (box)
● В коробке лежит какая-то ценность (value)
● У коробки есть замок (proposition)
● Чтобы открыть замок, нужен ключ (proof)
● Помимо value можно положить еще что-то
● Об открытых коробках можно забыть

25. Transactional layer: boxes
● Очень гибкая модель
● Не очень понятная интуитивно
● Большой размер транзакций
● Небольшая пропускная способность
● Микро остатки

26. Transactional layer: accounts
● Применяется в Ethereum, Waves, Nxt, …
● Аккаунты (публичные ключи) с изменяемым
балансом
● Ключ → подпись
● Нужна дополнительная защита от replay атак
● Minimal state – не просто key→balance

27. Transactional layer
Транзакционная модель это:
● Proposition (подпись, скрипт, ...)
● Box structure (структура минимального
элемента minimal state)
● Minimal state
● Transaction and transaction language
● Block

28. Возможные улучшения

29. Storage scalability
● SPV
● Rollerchain (https://arxiv.org/pdf/1603.07926.pdf)
● Authenticated data structures (ia.cr/2016/994)

30. Privacy
● Биткоин псевдоанонимен
● Есть анонимные форки – monero, zcache
● Composite signatures

31. Confirmation delay
● Биткоин – минимум 10 мин
● Более частые блоки – больше форков
● GHOST – используем блоки форков
● Bitcoin-NG, Byzcoin
● Быстрые подтверждения – больше доверия
(Dash)

32. Throughput
● Биткоин < 7 tx/s
● Уменьшение размера транзакций
● Lightning
● Bitcoin-NG, Byzcoin

33. Controllable
● Для внутренней валюты нужен контроль
● RsCoin - криптоваюта с центробанком

34. Практическая часть

35. Gateway
Block 1 Block NBlock 1
Block 1 Block 2 Block N-2 Block N-1 Block NBlock 1 Block M-3 Block M-2 Block M-1 Block M
Block N-2 Block N-1 Block NBlock N-3
GW
BTC
BTC assets

36. Gateway
Block 1 Block NBlock 1
Block 1 Block 2 Block N-2 Block N-1 Block NBlock 1 Block M-3 Block M-2 Block M-1 Block M
Block N-2 Block N-1 Block NBlock N-3
GW
BTC
BTC assets
Block 1 Block NBlock 1 Block N-2 Block N-1 Block NBlock N-3

37. Gateway
Block 1 Block 2 Block N-2 Block N-1 Block NBlock 1 Block M-3 Block M-2 Block M-1 Block M
GW
USD assets
BTC assets

38. Gateway
Пример: обмен Waves на ваш ассет
1. Выпустить asset, сохранить assetId
2. Запрашиваем высоту блокчейна
3. Запрашиваем блоки от последнего
обработанного до Height-N
4. Если нам пришли Waves – шлем в ответ
(или на адрес из attachment) ассеты
5. Если пришли ассеты – шлем в ответ Waves
6. Повторяем 2-5

39. Gateway
● Полученные монетки нужно безопасно
хранить
● Gateway – доверенное лицо

40. API: asset creation● Запрос
● Ответ
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' --header 'api_key: hsepassword' -d '{
"name": "MyAsset1",
"quantity": 1000000,
"description": "string",
"sender": "3Mxer4SkSwk4WTmn4zB5Zs54JU1LegiXSYw",
"decimals": 2,
"reissuable": true,
"fee": 1000000000
}' 'http://88.198.13.202/assets/issue'
{
"type": 3,
"id": "DU4ZTLahBUVctvMGUSMs6VSxd6Dj5WirBNtymoCywHeV",
"timestamp": 1478092161907,
"signature":
"59osdLQEZYXJaeAX367xjRTURKBEs5gaicXctU7rFUdh8Wtk9XUxiJykc8HxRDYYVzUgK2QCimKMj
ZiDEVH5Tshf"
"assetId": "DU4ZTLahBUVctvMGUSMs6VSxd6Dj5WirBNtymoCywHeV",
...
}

41. API: blockchain height● Запрос
● Ответ
curl -X GET --header 'Accept: application/json'
'http://88.198.13.202/blocks/height'
{
"height": 174725
}

42. API: block at height
● Запрос
● Ответ
curl -X GET --header 'Accept: application/json'
'http://88.198.13.202/blocks/at/174725'
{
"version": 2,
"timestamp": 1476245589713,
"transactions": [
{
"sender": "3MtCKcpwnQvK2fiVWsKJAhVEpXuFFopDqeE",
"assetId": null,
"attachment": "3MtCKcpwnQvK2fiVWsKJAhVEpXuFFopDqeE",
"amount": 1000000000
}
}

43. API: asset transafer● Запрос
● Ответ
curl -X POST --header 'Content-Type: application/json' --header
'Accept: application/json' --header 'api_key: hsepassword' -d '{
"recipient": "3N5H9zpmFepcTxqZPpjGqwbjBnnTvCeWzeR",
"assetIdOpt": "DU4ZTLahBUVctvMGUSMs6VSxd6Dj5WirBNtymoCywHeV",
"feeAmount": 100000,
"amount": 12,
"attachment": "base",
"sender": "3Mxer4SkSwk4WTmn4zB5Zs54JU1LegiXSYw"
}' 'http://88.198.13.202/assets/transfer'
{
"id": "DRFEtoNvYy6GNi4gnrkby1pC9wpBHjpUM2A5S4A9RPu6",
"sender": "3Mxer4SkSwk4WTmn4zB5Zs54JU1LegiXSYw",
"recipient": "3N5H9zpmFepcTxqZPpjGqwbjBnnTvCeWzeR",
"assetId": "DU4ZTLahBUVctvMGUSMs6VSxd6Dj5WirBNtymoCywHeV",
"amount": 12,
"timestamp": 1478157520635,
"attachment": "base",
...
}

44. Contacts
● http://www.slideshare.net/DmitryMeshkov
● https://twitter.com/DmitryMeshkov
● dmitry.meshkov@iohk.io