Files
SHiNE-server/docs/Blockchain/10_TECH_Blocks.md
T

105 lines
4.5 KiB
Markdown

# TECH блоки (`type=0`, `version=1`)
TECH-тип покрывает системные записи пользовательской цепочки. Все TECH DataItem имеют подписанный индексный тег:
```text
t=tech
```
`HEADER` является root TECH-линии. Следующие line-based TECH-события (`TECH_CREATE_CHANNEL`, `TECH_FORK`) образуют одну последовательность с `lineCode=0`, ссылкой на предыдущий TECH-событийный блок и sequence `1..N`.
## Подтипы
### `subType=0` — `HEADER_COMPAT`
Стартовый блок цепочки (`block #0`). Payload содержит tag `SHiNE`, login владельца и `initialBlockchainKey32`.
`initialBlockchainKey32` — public blockchain-signing key, которым был создан fork №1; это историческая точка происхождения. При последующих fork значение не меняется.
HEADER сам не хранит line-prefix, но является root TECH-линии.
### `subType=1` — `TECH_CREATE_CHANNEL`
Создание нового канала. Блок одновременно:
- является очередным шагом TECH-линии;
- является root нового канала;
- имеет `t=tech`;
- имеет `c_test5590=<canonical_channel_slug>`.
Начало body:
```text
[4] lineCode = 0
[4] prevTechBlockNumber
[32] prevTechBlockHash32
[4] techSequence
```
Далее идут `channelName`, `channelDescription`, `channelType`, `channelTypeVersion` согласно формату CREATE_CHANNEL.
### `subType=2` — `TECH_FORK`
`TECH_FORK` фиксирует создание нового fork и является обычным следующим шагом TECH-линии.
#### `TECH_FORK` body (`version=1`)
Big-endian:
```text
[4] lineCode = 0
[4] prevTechBlockNumber
[32] prevTechBlockHash32
[4] techSequence
[32] parentBlockchainKey
[4] forkPointBlockNumber
[32] forkPointBlockHash32
[8] forkPointTimestampMs
[4] parentTipBlockNumber
[32] parentTipBlockHash32
[8] parentTipTimestampMs
[4] discardedBlocksCount
[1] reasonCode
[2] commentUtf8Length
[N] comment UTF-8
```
- `prevTechBlockNumber` — глобальный blockNumber предыдущего TECH-события; если до fork не было CREATE_CHANNEL/FORK, это `HEADER #0`;
- `prevTechBlockHash32` — hash этого блока;
- `techSequence` — предыдущий TECH sequence + 1; первый TECH-событийный блок после HEADER имеет `1`.
Остальная fork-часть:
- `parentBlockchainKey[32]` — public key предыдущего fork;
- `forkPointBlockNumber[4]` — последний блок старой цепочки, сохранённый в новом fork;
- `forkPointBlockHash32[32]`;
- `forkPointTimestampMs[8]`;
- `parentTipBlockNumber[4]` — tip старой цепочки на момент начала ротации;
- `parentTipBlockHash32[32]`;
- `parentTipTimestampMs[8]`;
- `discardedBlocksCount[4] = parentTipBlockNumber - forkPointBlockNumber`;
- `reasonCode[1]`;
- `commentUtf8Length[2]`;
- `comment[N]` — максимум 1024 UTF-8 байт.
`reasonCode`:
- `1` — `ROUTINE_ROTATION`;
- `2` — `POSSIBLE_COMPROMISE`;
- `3` — `CONFIRMED_COMPROMISE_ROLLBACK`;
- `4` — `RECOVERY`.
Текущая схема ротации перепубликует выбранный префикс `0..forkPointBlockNumber` новым blockchain key и затем добавляет `TECH_FORK`. Перепубликованные Frame сохраняются байт-в-байт; внешняя ANS-104 owner/signature меняется. Новый blockchain key в body не дублируется: он определяется owner/signature нового DataItem.
## Серверная проверка TECH-линии
Для `TECH_CREATE_CHANNEL` и `TECH_FORK` сервер требует:
1. `lineCode=0`;
2. первый TECH-событийный блок ссылается на HEADER и имеет sequence `1`;
3. каждый следующий ссылается на фактический текущий хвост TECH-линии;
4. номер предыдущего блока, его hash и sequence должны совпадать точно.
Таким образом CREATE_CHANNEL и FORK образуют единый проверяемый технический позвоночник пользователя.