🇰🇷 🇬🇧

백서 UBMS

작성일: 2024-11-26
버전: 1.9
작성자: bokkamsun@gmail.com


목차

  1. 홍보
    • 1.1. 진화적 개발
    • 1.2. 독립적 코드베이스
    • 1.3. 시대적 배경
    • 1.4. 방향
  2. 기술 개요
  3. 경제 모델
    • 3.1. 인센티브
    • 3.2. 채굴 종류
      • 3.2.1. POW 작업증명 채굴
        • 3.2.1.1. 초반 채굴 설정
        • 3.2.1.2. 후반 채굴 설정
        • 3.2.1.3. 비트코인과 비교
        • 3.2.1.4. 채굴 설정 결론
      • 3.2.2. POS 지분증명 채굴
        • 3.2.2.1. 소각 메커니즘
      • 3.2.3. POB 행위증명 채굴
    • 3.3. 수수료
      • 3.3.1. 경제팩터
      • 3.3.2. 혼잡팩터
      • 3.3.3. 외부변수, 내부상수
      • 3.3.4. 수수료
      • 3.3.5. 비트코인과 이더리움의 수수료 비교
  4. 네트워크 구조
    • 4.1. PSAN 소개
    • 4.2. 청사진 (Blueprint) 개념
    • 4.3. UBMS 독자적 방식 주요 단계
    • 4.4. 노드 수별 Blueprint 예시
    • 4.5. 이더리움 PoS와의 비교
  5. UBMS 독창적 기술 특징
    • 5.1. 완전 독립적 코드베이스
    • 5.2. 합의 알고리즘
    • 5.3. 스마트 계약 대체 기술
    • 5.4. 역할다형성 자가조정 네트워크
    • 5.5. UTXO 기반 메타데이터 스마트 컨트랙트
      • 5.5.1. RGB vs 카르다노(eUTXO) vs UBMS 비교
    • 5.6. 독자기술 직렬화
      • 5.6.1. 직렬화 성능 및 특성 비교
      • 5.6.2. 평균 처리 시간
    • 5.7. 완전 분산형 구조
      • 5.7.1. 비콘체인(Beacon Chain)이 없다
  6. 가운영(준운영) 정의
  7. 블록체인 위기 대응 매뉴얼
  8. 참여자 위험 고지 (면책조항)
  9. 로드맵
  10. 부록 특허출원

1. 홍보

1.1. 진화적 개발

UBMS 프로젝트는 학습을 목적으로 시작한 프로젝트로, 진화적 발전 모델을 기반으로 설계되었습니다. 단계별 개발과 지속적인 개선 및 기능 추가를 목표로 하며, 끊임없이 발전하는 블록체인을 지향합니다. 초기 버전은 블록체인의 기본적인 형태로 출시되나, 지속적인 업데이트를 통해 점진적으로 발전할 예정입니다. 사용자에게는 초기에 다소 제한적인 기능만 제공되나, 이는 안정적인 시스템으로 나아가기 위한 필수적인 과정입니다. UBMS는 블록체인을 장기프로젝트로 삼아 "꾸준함이 승자의 유일한 전술이다"라는 철학에 따라 지속적인 개선을 약속합니다.

1.2. 독립적 코드베이스

UBMS는 자체 개발 블록체인으로, 서드파티 라이브러리와 개인 창작 코드를 활용하여 개발됩니다. 타 코인을 복사하거나 포크하지 않고 스스로 생산한 코드로 전체 프로젝트를 완전히 통제하며, 기존 레거시코드와 커플링이 없기에 모든 코드조각을 자유롭게 가공할 수 있고, 외부기술 종속에서 자유롭습니다. 도전적 시도와 다양한 개량을 달성하기 위한 기술적 토대를 마련하는데 의의를 두고 있습니다. 상기의 이유로 코드비용을 최소화할 수 있어 장차 개량과 확장에 유리합니다.

1.3. 시대적 배경

블록체인은 이미 학문 및 교육 커리큘럼에 포함된 레거시 기술로 자리잡았으며, 금융 산업 및 다양한 산업 분야에서 중요한 역할을 수행합니다. 세계 각국은 연구 및 개발에 막대한 자금을 투입하나, 생각보다 느린 기술 발전 속도와 기본 아이디어에서 뚜렷한 진보가 없어, 여전히 도전할 이유로 충분합니다.

1.4. 방향

UBMS(UTXO-Based Metadata Smart Contract)는 기존 비트코인의 한계를 극복하기 위한 독창적인 기술적 접근을 시도합니다. 열정과 의지를 바탕으로, 시대의 필요에 부합하는 기술을 지속적으로 개발하겠습니다.


2. 기술 개요

구성 요소기술 내용
합의 메커니즘PoW + PoS + PoB 통합 하이브리드 시스템
네트워크 구조PSAN: 역할다형성 자가조정 네트워크, 임계값 기반 릴레이/투표자 계산
합의 메시지 최적화릴레이/투표자 수를 로그함수 기반으로 설정하여 메시지 수 최소화 (Data Storming 억제)
전파 구조TTL=5, XOR 모듈러2 기반 피어 거리 계산, 효율적 Gossip 설계
채굴 구조초기 채굴 존재, 반감기 720블록, PoW → PoS 전환 기반 구조
인센티브 구조채굴자 5%, 지분 보유자 95% 온체인 자동 (스테이킹 기반 PoS 인센티브)
행위증명 시스템POB: 5단계 디스트리뷰터 수수료, 전송 트리 구조로 인센티브 자동 계산/기록
수수료 정책시장가 기반 경제팩터 + 혼잡도 기반 혼잡팩터 x 기준수수료 공식 적용
스마트 컨트랙트UTXO 기반 페이로드 확장 구조, 조건문, TTL, 조건 실행 지원
컨트랙트 비교 설계RGB/eUTXO 대비 온체인/오프체인 혼합 실행, 데이터 수정성, TTL, 조건 실행 지원
직렬화 방식템플릿 기반 고속 직렬화, 구조체 공용체 기반 메모리 직접 복사 방식
직렬화 성능평균 처리 시간 0.15ms, FlatBuffers/ProtoBuf 대비 최소 오버헤드 구현
분산성 구조비콘체인 없는 완전 분산 구조, 릴레이/투표자가 전담, 단일 실패점 제거
노드 최소 구성릴레이 3, 투표자 5, 채굴자 1 → 최소 9노드로 완전한 합의 가능
청사진 시스템$\log_2(N)$ 기반 BP 계산식으로 노드 수 증감에 따라 네트워크 자동 조정
미래 확장성DSCB(Dynamic Self-Computing Block) 기반 스마트 계약 예정

UBMS는 위와 같은 독창적 기술들을 바탕으로, 자율적이고 합리적인 블록체인 생태계를 장기적으로 실현하는 것을 목표로 합니다.


3. 경제 모델

3.1. 인센티브 규칙

UBMS의 채굴 인센티브는 채굴자의 기여도와 참여자의 지분에 따라 공정하게 처리됩니다.


3.2. 채굴 종류

3.2.1. POW 작업증명 채굴

3.2.1.1 초반 채굴 설정

작업증명 채굴은 지분증명 채굴과 일정 비율로 나누게 됩니다. 아래는 채굴 총량을 기준으로 계산합니다.

기본 계산

반감기 간격 및 인센티브 설정

초기 채굴 단계 요약

구간별 인센티브:

  1. 1구간: $R_0 = 1{,}000$ UBMS/block
  2. 2구간: $R_0/2 = 500$ UBMS/block
  3. 3구간: $R_0/4 = 250$ UBMS/block
  4. 4구간: $R_0/8 = 125$ UBMS/block

구간별 블록 수: 540블록씩 (총 2,160블록)

구간별 채굴량:

$C_{1,1} = 1{,}000 \times 540 = 540{,}000$
$C_{1,2} = 500 \times 540 = 270{,}000$
$C_{1,3} = 250 \times 540 = 135{,}000$
$C_{1,4} = 125 \times 540 = 67{,}500$

총 채굴 코인 수:

$$C_1 = 540{,}000 + 270{,}000 + 135{,}000 + 67{,}500 = 1{,}012{,}500 \; \text{UBMS}$$

3.2.1.2 후반 채굴 설정

기본 계산

후반 채굴 단계 요약

구간별 인센티브 및 채굴량:

$\text{5구간: } 48 \times 210{,}240 = 10{,}091{,}520$
$\text{6구간: } 24 \times 210{,}240 = 5{,}045{,}760$
$\text{7구간: } 12 \times 210{,}240 = 2{,}522{,}880$
$\text{8구간: } \;\;6 \times 210{,}240 = 1{,}261{,}440$
$\text{9구간: } \;\;3 \times 210{,}240 = 630{,}720$
$\text{10구간: } 1.5 \times 210{,}240 = 315{,}360$
$\text{11구간: } 0.629 \times 210{,}240 \approx 132{,}320$

총 후반 채굴 코인 수:

$$C_2 \approx 20{,}000{,}000 \; \text{UBMS}$$

3.2.1.3 비트코인과 비교

구분비트코인UBMS
반감기 간격210,000블록 (약 4년)210,240블록 (4년, 10분/블록 가정)
초기 인센티브50 BTC/block48 UBMS/block (후반 초기 인센티브)
총 공급량21,000,000 BTC약 21,012,500 UBMS (초반 1,012,500 + 후반 20,000,000)

3.2.1.4 채굴 설정 결론

단계총 채굴 코인 수총 블록 수반감기 간격초기 인센티브반감기 횟수
초반 채굴1,012,500개2,160블록540블록 (블록 생성 간격 10초)1,000 UBMS/블록4회
후반 채굴19,552,320개1,051,200블록210,240블록 (4년, 10분/블록)48 UBMS/블록5회
구분반감기 번호블록당 인센티브 (UBMS)단계 총 채굴량 (UBMS)블록 높이누적 채굴량 (UBMS)
초반 채굴11,000540,0000 ~ 539540,000
초반 채굴2500270,000540 ~ 1,079810,000
초반 채굴3250135,0001,080 ~ 1,619945,000
초반 채굴412567,5001,620 ~ 2,1591,012,500
후반 채굴54810,091,5202,160 ~ 212,39911,104,020
후반 채굴6245,045,760212,400 ~ 422,63916,149,780
후반 채굴7122,522,880422,640 ~ 632,87918,672,660
후반 채굴861,261,440632,880 ~ 843,11919,934,100
후반 채굴93630,720843,120 ~ 1,053,35920,564,820
후반 채굴101.5315,3601,053,360 ~ 1,263,59920,880,180
후반 채굴110.75157,6801,263,600 ~ 1,473,83921,037,860
구간 번호블록 높이 시작블록 높이 끝블록 개수
1구간0539540개
2구간5401,079540개
3구간1,0801,619540개
4구간1,6202,159540개
구간 번호블록 높이 시작블록 높이 끝블록 개수
5구간2,160212,399210,240개
6구간212,400422,639210,240개
7구간422,640632,879210,240개
8구간632,880843,119210,240개
9구간843,1201,053,359210,240개

모든 채굴공급의 합은 대략 2100만개이지만 POS 소각분을 빼면 더 적습니다.


3.2.2. POS 지분증명 채굴

UBMS의 POS 채굴은 온체인 방식으로 모든 스테이킹 과정이 블록체인에 기록되며, UBMS SCAN을 통해 누구나 투명하게 확인할 수 있습니다.

기존의 단순 비례 대신, UBMS는 Shifted Sigmoid 함수 기반의 알고리즘을 도입하였습니다. 이 방식은 고지분 참여자의 과도한 독점을 방지하도록 비선형적 곡선 보정을 적용합니다.

인센티브 공식

스테이커 개별 인센티브는 다음과 같이 계산됩니다.

Sigmoid 가중치 계산

$$R(x) = \frac{1}{1 + e^{-z}}$$ $$z = \left( \frac{x + s}{T} - 0.5 \right) \times 10$$
$R$ : 시그모이드
$z$ : 입력값으로 이곳을 조정해 시프트시킨다
$x$ : 스테이커의 지분 수량
$T$ : 전체 스테이커 지분 총합
$r = 0.2$ : 좌측시프트 비율
$s = T \times r$ : 시프트값
10을 곱한 것은 소지분자와 대지분자의 차이를 뚜렷하게 하여 유의미한 차이를 만든다

이로부터 나온 각 참여자의 R(x) 값을 전체 합으로 정규화하여 사용합니다.

예시 시뮬레이션

$$\text{지분당 인센티브}(x) = 95 \times \frac{R(x)}{\sum R(x_i)}$$ $$z = \left( \frac{x + (T \times 0.2)}{T} - 0.5 \right) \times 10$$ $$T = 10{,}000, \quad s = T \times 0.2 = 2{,}000$$

지분자별 결과 (Sigmoid 적용)

참여자지분 수량비율 (%)인센티브 (UBMS)
A1002.25%2.14
B2004.04%3.83
C3006.01%5.71
D5008.89%8.45
E80012.23%11.62
F1,30015.13%14.37
G1,60016.48%15.66
H1,80016.64%15.81
I1,90016.48%15.66
J1,50012.37%11.75
합계10,000100%95.00

UBMS 인센티브 알고리즘의 장점


3.2.2.1 소각 메커니즘

UBMS의 PoS 인센티브 분배 시스템에는 참여 노드 수가 적을 때 일부 인센티브를 자동 소각(Burn)하는 공급 조절 메커니즘이 내장되어 있습니다.

소각 공식 및 구조

PoS 소각 메커니즘(노드 수 기준)

공식

$$\text{PoS 분배율} = \max(0.01,\; \min(1,\; \frac{N}{10{,}000})) \times 100\%$$ $$\text{PoS 소각률} = \left(1 - \max(0.01,\; \min(1,\; \frac{N}{10{,}000}))\right) \times 100\%$$

분배되는 PoS 할당량은 Shifted Sigmoid 가중치로 각 참여자에게 배분됩니다. 소각되는 분량은 완전히 소멸되어 누구도 가져갈 수 없습니다.

실제 동작 예시 (PoS 할당량 기준)

노드 수분배 비율소각 비율비고
00%100%PoS 보상 전액 소각
1001%99%1%만 분배, 99% 소각
1,00010%90%10%만 분배, 90% 소각
5,00050%50%50%만 분배, 50% 소각
9,50095%5%95%만 분배, 5% 소각
10,000 이상100%0%전액 분배, 소각 없음

설계 의도와 효과

UBMS의 인센티브 구조는 총 인센티브 5%는 PoW 채굴자, 95%는 PoS 할당량이며, 노드 수가 적으면 PoS 분량이 자동으로 소각됩니다. 즉, 노드 10,000개면 PoS 100% 분배, 노드 100개면 PoS 1%만 분배(나머지 소각)입니다.


3.2.3. POB 행위증명 채굴

POB 행위증명 채굴은 사용자가 코인을 전송할 때 발생하는 수수료(fee)를, 네트워크 확장에 기여한 사람들에게 인센티브를 제공하는 온체인 방식의 채굴입니다. 행위증명의 인센티브는 블럭에 기록되고 UBMS 시스템이 수행하기에 누락이 없고 행위의 인센티브를 보장합니다. 여기서 디스트리뷰터란 UBMS 네트워크 실제적인 확장에 기여한 사용자의 지갑 주소를 의미하며, 이 주소가 반드시 입력되어야만 UBMS 코인이 올바르게 작동합니다.

수수료 인센티브 원리

거래 전송 시 발생하는 수수료는 최대 5단계까지 자동관리됩니다.

단계인센티브 비율인센티브 금액 (원)
1대60%1,000 x 0.60 = 600
2대20%1,000 x 0.20 = 200
3대10%1,000 x 0.10 = 100
4대7%1,000 x 0.07 = 70
5대3%1,000 x 0.03 = 30

디스트리뷰터 트리 구조 예시

18eAuVSXcQ5Gdz6GVCd611TtwAxmhD5dXW  (level 0)
├── 1Aj4YWxVi9rbKnnDN9T6dohVcfSxqBJ2JD  (level 1)
│   ├── 1GqZ5QuLQe5YxDFyLBcDkPn9hpLX7dGge2  (level 2)
│   └── 1HgQt3TfcQz9xz1bDNZDnVSmM1d99FQ2pb  (level 2)
│       ├── 1JmLNR1dY65kZJACbzyKqu2SGnTpM1bZPx  (level 3)
│       │   ├── 1MMMAsyH3qLFFcex3uJ2qAjSDCzu4qobv5  (level 4)
│       │   │   ├── 1PgpaijEyheTQ2DdzK25Kosm2awWtzcHdK  (level 5)
│       │   │   ├── 1PqjsiCuQjhGJaDky2s35H4P7dGfQ3uoaM  (level 5)
│       │   │   └── 1U25D13kfGUGDScQ8uVg7kjqcdHtYSFCh  (level 5)
│       │   ├── 1NQ4GMcxZQjFUPB7Ahej4XUsMWoLy7Uu33  (level 4)
│       │   └── 1NUPTVBfuk6fjt21cqPoKA3HT7gDaXLCUi  (level 4)
│       └── 1Jyh4WjUgQ4HL4WjbtTuR6jviw2SMixErT  (level 3)
└── 1BhpGXNKTQhuJsWAGS8PGudx11FrRLz6n6  (level 1)

POB 관련 오픈베타테스트를 통해 얻은 교훈으로 POB유지가 트래픽유발이 심각하여 시스템이 감당할 수 없는 경우 예고없이 패치를 통해 중단될 수 있습니다.


3.3.2. 혼잡팩터

혼잡팩터는 최근 250개 블록의 네트워크 혼잡도를 측정하여 산출됩니다. 네트워크에 대기 중인 거래 수를 기반으로 하며, 혼잡도가 높을 경우 혼잡팩터 CF는 1.0보다 큰 값으로 조정됩니다. 이를 통해 네트워크 혼잡 상황에서는 추가 수수료를 인상하여 스팸 트랜잭션을 방지하고, 네트워크의 안정성을 확보할 수 있도록 설계되어 있습니다.

3.3.3. 외부변수

항상 부정확한 경제팩터를 얻기 위해 트랜잭션을 조사하여 시장가를 추론할 필요가 없습니다. 우리가 알고 싶은 시장가는 시스템 밖의 코인마켓캡과 같은 가격공시 사이트로부터 수신되는 외부정보를 참고합니다. 이 변수값은 1 UBMS당 시장가의 기준 가격을 제공하며, 기저 수수료 산출에 필수적입니다. 기존 업체들은 내부 계산 방식에만 의존하다 보니 비현실적인 높은 수수료 정책을 적용하는 경우가 많으나, UBMS는 외부 데이터를 활용하여 보다 현실적이고 합리적인 수수료 정책을 구현합니다.

3.3.4. 수수료 계산

외부에서 수신한 1 UBMS의 시장가를 기준으로 기저 수수료가 결정됩니다.

최종 수수료:

$$F = B \times EF \times CF = 1{,}000 \times \sqrt{\frac{v}{10{,}000}} \times CF$$

예시 1: (시장가 v = 10,000 원)

$EF = \sqrt{10{,}000 \;/\; 10{,}000} = 1$
$CF = 1.0$
$F = 1{,}000 \times 1 \times 1.0 = 1{,}000$ 원

예시 2: (시장가 v = 100,000,000 원)

$EF = \sqrt{100{,}000{,}000 \;/\; 10{,}000} = 100$
$CF = 1.0$
$F = 1{,}000 \times 100 \times 1.0 = 100{,}000$ 원

시장가별 수수료 표

시장가 v (원)sqrt(v/10,000) 값최종 수수료 F (원)
1,000약 0.316약 316
10,00011,000
100,000약 3.162약 3,162
1,000,0001010,000
10,000,000약 31.623약 31,623
100,000,000100100,000

비트코인과 이더리움의 수수료

비트코인 — 수수료는 주로 트랜잭션의 바이트 크기와 네트워크의 혼잡도에 따라 결정됩니다. 낮은 거래 금액에서도 네트워크 혼잡 시 몇 천 원에서 수 만 원대의 수수료가 발생할 수 있으며, 거래 금액과 무관하게 고정된 수준의 수수료가 부과되는 경향이 있습니다.

이더리움 — 수수료는 가스 가격과 가스 사용량에 따라 결정됩니다. 복잡한 스마트 계약이나 네트워크 혼잡 시, 수수료는 몇 천 원에서 수 만 원, 때로는 그 이상이 될 수 있으며, 거래 금액과 비례하지 않고 트랜잭션의 복잡성과 네트워크 상황에 크게 좌우됩니다.

거래 금액 (원)비트코인 수수료 (원)이더리움 수수료 (원)UBMS 수수료 (원)
1,000약 3,000 ~ 5,000약 3,000 ~ 5,000약 316
10,000약 3,000 ~ 5,000약 3,000 ~ 5,0001,000
100,000약 5,000 ~ 7,000약 5,000 ~ 7,000약 3,162
1,000,000약 5,000 ~ 10,000약 5,000 ~ 10,00010,000
10,000,000약 10,000 ~ 15,000약 10,000 ~ 15,000약 31,623
100,000,000약 10,000 ~ 15,000약 10,000 ~ 15,000100,000

도표는 비트코인과 이더리움 혼잡팩터 CF 1.0을 기준으로 네트워크 혼잡 시 10배까지 증액됩니다. 송금 1,000원에 수수료 5,000원? 혼잡 시 10배 10,000 ~ 50,000원? 급격한 혼잡이나 특정 이벤트(예: 대규모 ICO, NFT 발매 등)가 발생하면, 심지어 1건당 수수료가 30,000원에서 수십만원 이상으로 급등하는 사례도 보고되고 있습니다. 비트코인과 이더리움의 수수료가 불합리한 것은 네트워크 내부 트랜잭션을 모집단으로 EF를 산출하기 때문입니다. 자유시장 경제에 의존하여 수요공급으로 가치가 결정되는 암호화폐가 화폐유통을 중계하거나 시장가치를 공시하는 거래소의 등장을 예측하지 못했을까요? 개발자의 아집과 외부시장과 시스템과의 소통단절이 부른 대참사라고 할 수 있습니다.


3.3.5. 결론 (수수료 비교)

UBMS의 수수료 공식은 외부에서 수신한 시장가와 내부상수로 결정된 기저 수수료 그리고, 경제팩터 및 최근 250개 블록의 혼잡도를 반영한 네트워크 혼잡팩터를 곱하여 최종 수수료를 산출합니다. 따라서, 시장가가 낮은 경우 (1 UBMS당 10,000원 기준)에는 1,000원의 수수료가 적용되며, 시장가가 높은 경우 (1 UBMS당 100,000,000원 기준)에는 100,000원의 수수료가 적용됩니다. 특히, 중대형 거래에서는 매우 낮은 수수료 비율을 제공하여 거래 비용 부담을 크게 줄입니다. 반면, 비트코인과 이더리움은 거래 금액과 무관하게 고정되거나 네트워크 혼잡에 따른 높은 수수료가 부과되어, 낮은 거래에서는 부담이 크고 고액 거래에서는 비례성이 떨어지는 단점을 보입니다. 이와 같이 UBMS의 수수료 정책은 현실적인 시장 상황과 네트워크 상태를 반영한 전략적인 수수료율을 제공함으로써, 기존 방식보다 합리적입니다.


4. 네트워크 구조

4.1. UBMS의 혼잡방지 기술 PSAN (Role-Polymorphic Self-Adjusting Network) 소개

4.2. 청사진 (Blueprint) 개념

네트워크 노드 수에 맞춰 BP함수로 계산된 홀수 개의 릴레이(relay)와 투표자(voter)를 사용합니다.

4.3. UBMS 독자적 방식 주요 단계

이더리움과 비교하면 UBMS 네트워크는 비콘체인이 없고 구조적, 절차적으로 단순하고 가볍습니다. 비트코인은 네트워크 구조가 달라 수평비교가 안되어 이하 도표에서 생략합니다.

  1. 릴레이 (R) 및 투표자 (V) 선정 (BP함수 적용)
  2. 투표를 통한 채굴자 (Miner) 선정 — 투표자는 스테이크 기반 가중치로 투표, 릴레이가 결과를 수합
  3. 채굴자가 블록 생성 후 검증 — 투표자들이 다수결로 블록 승인
  4. 블록 전파 (gossip) — Miner → 투표자 → 전체 네트워크
  5. 하트빗 시 CF 폭증 억제 — 블록 업데이트 후 전체 노드가 하트빗 (UBMS 하트빗은 이더리움의 노드 디스커버리 기능을 겸하고 있어 효율적)
  6. DHT로 롤백 — 블록 해시가 다수와 다르면 인접 노드에서 롤백을 지원

4.4. 노드 수별 BP 예시

UBMS gossip 프로토콜은 TTL이 5로 기본값 설정되어 있으며, 한 번의 전파에서 최대 5개의 논리적으로 가까운 피어를 사용합니다. 피어간의 거리계산은 모듈러2(XOR연산) 함수를 사용합니다.

최소 3개의 relay 노드, 5개의 vote 노드가 존재해야 하고 추가로 1명의 채굴자가 있어야 하기에 네트워크에서 필요한 최소노드수는 9개입니다.

다수결 원칙을 명확히 하기 위해 항상 홀수로 설정합니다.

BP 계산식:

$$R = \max\!\left(3,\; \lfloor \frac{\log_2 N}{2} \rfloor \times 2 + 1\right)$$ $$V = \max\!\left(5,\; \lfloor \frac{\log_2 N}{1.2} \rfloor \times 2 + 1\right)$$

청사진값 예시:

$N=100 \;\;\;\;\;\; \log_2(100) \approx 6.64 \;\;\; \Rightarrow R=3, \;\; V=11$
$N=1{,}000 \;\;\; \log_2(1{,}000) \approx 9.96 \;\;\; \Rightarrow R=5, \;\; V=21$
$N=10{,}000 \;\; \log_2(10{,}000) \approx 13.28 \; \Rightarrow R=7, \;\; V=51$
$N=100{,}000 \; \log_2(100{,}000) \approx 16.61 \; \Rightarrow R=11, \; V=101$

R, V 규모를 과도하게 키우지 않고, 필요할 때만 조금씩 늘려 메시지 폭발을 방지합니다.

4.5. 이더리움 PoS와의 비교 - 노드 수별 테이블

4.5.1. 노드 수: 100개

항목UBMS이더리움 PoS비고
릴레이/투표자R=3, V=11위원회 약 128명UBMS 선정 메시지 훨씬 적음
합의 메시지투표(11x3=33), 검증(11), 하트빗(100)위원회 투표 128건+, gossip(100건+)UBMS가 초기 합의에 필요한 메시지 적음
CF(혼잡 트래픽)100노드 정도면 하트빗도 크지 않음이더리움도 비슷하게 부담 적음소규모에선 둘 다 빠르고 안정적

4.5.2. 노드 수: 1,000개

항목UBMS이더리움 PoS비고
릴레이/투표자R=5, V=21위원회 128~256명UBMS는 소수 릴레이, PoS는 위원회 증가
합의 메시지투표(21x5=105), 검증(21), 하트빗(1,000)위원회 투표(128~256건+), gossip(1,000건+)UBMS 합의가 단순/메시지 절약
CF(혼잡 트래픽)하트빗 1,000건 발생하나 투표/검증은 간단PoS도 gossip 1,000건, 위원회가 커짐UBMS가 합의 속도가 빠름

4.5.3. 노드 수: 10,000개

항목UBMS이더리움 PoS비고
릴레이/투표자R=7, V=51위원회 약 512명UBMS는 소수 릴레이, PoS 위원회 512명
합의 메시지투표(51x7=357), 검증(51), 하트빗(10,000)위원회투표 512+, gossip 10,000+UBMS 초기 합의 적은 메시지, CF는 노드 수만큼 발생
CF(혼잡 트래픽)하트빗 10,000건으로 혼잡 위험PoS도 gossip 10,000건 이상둘 다 대규모, UBMS 합의부담은 상대적 경량

4.5.4. 노드 수: 100,000개

항목UBMS이더리움 PoS비고
릴레이/투표자R=11, V=101위원회 수천명 이상UBMS는 제한적 합의, PoS는 위원회가 기하급수적 증가
합의 메시지투표(101x11=1,111), 검증(101), 하트빗(100,000)수천~만건 위원회, gossip 100,000+UBMS 투표/검증은 적으나 하트빗이 100,000건 이상
CF(혼잡 트래픽)샤딩/AI 등 추가 기술 없으면 혼잡 매우 클 수 있음PoS도 샤딩 없인 병목 심각초대형 규모에서 둘 다 확장성 기술이 필요

참고로 현재 기준 비트코인은 약 2만개, 이더리움은 1만개 이하의 노드가 활성화되어 있습니다.


5. UBMS 독창적 기술 특징

5.1. 완전 독립적 코드베이스

UBMS는 기존 암호화폐 프로젝트와 차별화된 독창적 기술을 기반으로 합니다. 타 프로젝트의 포크 없이 자체 개발된 코드베이스를 통해 기능 추가와 보안 강화를 실현합니다.

5.2. 합의 알고리즘

가볍고 빠르게 작동하는 독자 개발한 합의알고리즘과 PoW, PoS, PoB를 통합한 하이브리드 메커니즘을 도입하여 에너지 효율성과 네트워크 안정성을 극대화합니다.

5.3. 스마트 계약 대체 기술

장차 업데이트할 동적 자가연산 블록(Dynamic Self-Computing Block) 기술을 통해 기존 스마트 계약의 한계를 극복하며 높은 유연성과 확장성을 제공할 예정입니다.

5.4. 역할다형성 자가조정 네트워크

PSAN (Role-Polymorphic Self-Adjusting Network)는 네트워크 혼잡을 해결하기 위한 UBMS의 네트워크 독자 솔루션입니다. 자세한 내용은 상기의 4. 네트워크 구조에 상세히 설명하였습니다.

5.5. UTXO 기반 메타데이터 스마트 컨트랙트

비트코인의 UTXO 모델을 기반으로 하면서도 스마트 컨트랙트를 실행할 수 있는 독창적 UBMS 구조를 미리 설계하였고, 스마트 컨트랙트 부분은 UBMS의 동적 자가연산 블록(Dynamic Self-Computing Block) 기술로 장차 구현할 예정입니다.

5.5.1. RGB 프로토콜 vs. 카르다노(eUTXO) vs. UBMS 비교

비교 항목RGB 프로토콜카르다노(eUTXO)UBMS
확장성제한적 확장병렬 처리로 높은 확장성페이로드 기반으로 유연한 확장
표현 방식UTXO에 토큰 상태만 저장UTXO 자체에 검증 포함UTXO의 페이로드에서 수행
실행 방식온체인 실행 불가능트랜잭션 검증 시 실행 (온체인)온체인/오프체인 혼합 방식
데이터 저장 위치오프체인에서 관리블록체인 내부에 저장UTXO 내부 페이로드로 저장
조건 기반 여부지원하지 않음특정 조건 만족 시 실행CONDITION에서 조건 설정 후 실행
수명주기(TTL) 설정지원하지 않음지원하지 않음TTL 필드에 직접 포함
변경 가능성토큰 발행 후 변경 불가한 번 생성된 eUTXO는 변경 불가데이터 일부 수정 가능
오프체인 데이터 저장대부분 오프체인에서 처리온체인에서 모든 검증 수행일부 데이터를 오프체인에서도 관리
블록체인 과부하 문제별도의 오프체인 검증 필요온체인 실행으로 과부하 발생페이로드 최적화로 과부하 방지
개발자 친화성비트코인 스크립트 기반으로 복잡Plutus/Haskell 사용UTXO 기반으로 쉽게 사용
보안성비트코인 보안 모델 유지높은 보안블록체인+오프체인 조합으로 보안 강화

UBMS는 사전에 확장성을 최우선에 두고 설계되었기에, 장차 기술 접목에 유리합니다.

5.6. 독자기술 직렬화

UBMS는 통신을 위한 경량 직렬화를 구현하였고 매우 유연하고 성능이 뛰어납니다.

5.6.1. 직렬화 성능 및 특성 비교

비교항목비트코인 직렬화이더리움 RLPUBMS 직렬화
속도단순한 버퍼 조작으로 최소 오버헤드, 매우 빠름재귀적 처리와 길이 계산 등으로 오버헤드가 있어 느림템플릿 기반 최적화로 직접 메모리 복사하여 최고 빠름
메모리간단한 버퍼 연산으로 메모리 사용이 매우 효율적동적 메모리 할당 및 재귀 호출로 추가 메모리 사용고정 사이즈 데이터 및 템플릿 처리로 불필요한 메모리 사용 최소화
코드커스텀 구현이지만 구조가 단순하여 중간 정도의 복잡성다양한 데이터 타입과 중첩 구조라 복잡하고 구현 난이도가 높음S_MESSAGE 공용체로 모든 유형의 구조체를 전달할 수 있어 간단함
확장성고정된 데이터 구조로 확장이 제한적다양한 데이터 구조 지원은 가능하나, 재귀적 설계로 확장 시 구현 복잡템플릿 특수화로 새로운 데이터 타입 추가가 용이하여 확장이 뛰어남
디버깅단순한 구조로 인해 디버깅 및 유지보수가 수월함복잡한 재귀 구조로 인해 에러 발생 시 추적 및 수정이 어려울 수 있음표준 C++ 코드와 템플릿 구조로 일관된 코드 사용으로 유지보수가 용이함
유연성특정 데이터 구조에 최적화되어 있어 유연성은 낮은 편다양한 데이터 타입과 중첩 지원하지만, 그에 따른 성능 저하가 단점모든 유형의 데이터 전달 가능하며 성능이 뛰어남

5.6.2. 평균 처리 시간

직렬화 기법평균 처리 시간 (ms)상세 설명
UBMS 직렬화0.15템플릿 기반 최적화와 직접 메모리 복사로 가장 빠름
FlatBuffers0.18빠른 메모리 접근 및 최소 오버헤드, 우수한 성능
Protocol Buffers0.20스키마 기반 직렬화로 효율적이나 약간의 오버헤드 존재
비트코인 직렬화0.25단순 버퍼 조작 방식으로 빠르나, UBMS보다는 다소 느림
Boost.Serialization0.50복잡한 구조로 인한 오버헤드로 비교적 느림
이더리움 RLP0.80재귀적 처리와 길이 계산 등으로 가장 많은 오버헤드 발생

5.7. 완전 분산형 구조

5.7.1. 비콘체인(Beacon Chain)이 없다


6. 가운영(준운영) 정의

  1. 오픈 베타 테스트 이후 실제 블록 생성 단계부터 '가운영'을 시작하며, 월 단위로 지속적인 패치를 통해 코드 안정화 작업을 진행한다.
  2. 가운영 기간은 2026~2027년 소스코드를 GitHub에 공개하기 전까지 계속된다.
  3. 참여자는 미성숙한 코드로 인해 발생할 수 있는 각종 문제를 사전에 충분히 인지하였으므로, 모든 참여자는 가운영 기간 중 발생하는 사건/사고를 감수한다.
    참여자란 채굴자, 앱 사용자, UBMS 코인 프로젝트 생태계 참여자 일체를 말한다.
  4. 비트코인 개발 초기(약 2~3년) 동안 집중적으로 사건/사고가 발생한 사례를 참고하여, 초기 운영 단계에서는 단계별 구분과 주의가 필요함을 모두가 인식하고 동의한다.
  5. 가운영 사실과 이에 동의하는 절차는 앱 시작 시 체크박스 형태로 표시하여, 참여자로부터 명시적인 동의를 받는다.
  6. 가운영 기간 동안 예상되는 사건/사고 유형으로는 시스템 공격(네트워크 DDoS, 노드 탈취 등), 블록 변조 시도, 코드 취약점을 노린 공격, 체인 롤백, 그 외 버그로 인한 장애 등이 있다.
  7. 참여자는 가운영 기간 중 발생하는 모든 사건/사고가 코드 개발과 IT 서비스 운영의 필연적인 과정임을 인정하고, 귀책을 묻지 아니하며, 개발 주체가 지속적인 시간과 노력을 투입해 문제를 해결하도록 조력한다.
  8. 가운영 상태에서는 홍보가 미미하여 참여자가 느리게 성장하기에, 개발주체는 보유량 일부를 사용해 특정 참여자에게 자원의 집중이 되지 않도록 하거나, 급과열/급냉각에 의한 시장가치 왜곡을 예방하고 안정적인 성장을 조력한다.

7. 블록체인 위기 대응 매뉴얼

위기 대응 프로세스 및 책임 명시

1. 위기상황 정의
해킹, 장애, 네트워크 공격, 블록체인 데이터 변조, 중대한 버그, 체인 롤백, 하드포크 및 기타 운영상 중대한 장애를 위기 상황으로 정의합니다.

2. 초기 대응 절차
문제가 발견될 경우 즉시 개발자 또는 운영진이 긴급 점검 및 일시적 블록 생성을 중지할 수 있습니다. 주요 이슈는 공식 커뮤니티 및 공지 채널(홈페이지, 포럼 등)에 신속하게 상황을 알립니다.

3. 조치 및 의사결정
장애 복구, 롤백, 하드포크 등 중대한 조치가 필요할 경우, 가운영 기간 중에는 개발자/운영진의 단독 판단으로 즉각적 패치 또는 롤백, 하드포크를 시행할 수 있습니다. 조치 이후 상세 내역과 복구 절차, 영향 범위를 공식 채널을 통해 투명하게 안내합니다.

4. 인센티브 및 책임 범위
가운영 기간 중 발생한 모든 손실(코인 손실, 거래 오류 등)에 대해 참여자는 사전에 리스크를 충분히 인지하고 동의하며, 개발자 및 운영진에게 민/형사상 책임을 묻지 않습니다.

5. 최종 결정권
정식 오픈(소스 공개) 이전까지 모든 긴급 상황의 최종 결정권은 개발자(또는 운영진)에 귀속됩니다. 소스 공개전에는 개발자 또는 운영진이 임의의 판단 하에 즉각적으로 시스템 중단 및 복구 조치 가능합니다. 오픈소스 전환 및 분산화 이후에는 커뮤니티 및 네트워크 합의에 따라 주요 결정을 진행합니다.


8. 참여자 위험 고지 (면책조항)

위험 고지 및 책임의 한계

  1. 본 프로젝트(UBMS)는 기술적 실험적 프로젝트로 금융투자 상품이나 증권이 아닙니다.
  2. 회원정보 및 개인식별 정보를 수집하거나 관리하지 않습니다.
  3. 오픈 베타 및 가운영(준운영) 상태로서, 아직 코드 및 시스템의 완전성이 검증되지 않은 단계임을 명시합니다.
  4. 모든 참여자(채굴자, 사용자, 노드 운영자 등)는 다음의 위험을 사전에 충분히 인지하고, 이에 동의한 경우에만 참여해야 합니다:
    • 해킹, 장애, 데이터 손실, 코인 소실, 체인 롤백, 하드포크, 임의의 코드 수정 등 예기치 못한 문제로 인해 발생할 수 있는 모든 손실
  5. 개발자 및 운영진은 가운영 기간 중 발생하는 모든 사건/사고에 대해 최대한 신속하고 성실하게 복구/대응할 것이나, 이로 인해 발생하는 직/간접적 손실 및 책임에 대해 법적/금전적 책임을 지지 않습니다.
  6. 참여자는 앱, 지갑, 채굴 프로그램 실행 전 반드시 위험 고지 및 책임의 한계에 동의합니다라는 체크박스 또는 동의 버튼을 확인해야 하며, 이를 통한 동의 절차가 완료되지 않으면 시스템 이용이 제한됩니다.
  7. 가운영 종료 및 소스 공개 이후에는, 네트워크의 의사결정 및 운영 책임이 커뮤니티 및 네트워크 합의에 이관됩니다.

9. 로드맵

  1. 오픈 베타 테스트 진행 — 초기 기능을 검증하고, 사용자 피드백을 반영해 안정성을 높입니다.
  2. 백서 버전 1.0 완성 — 프로젝트 목표, 경제 모델, 기술 사양 등을 정리한 공식 문서를 완성합니다.
  3. 가운영(준운영) 시작 — PoW와 PoB 방식으로 실제 블록을 생성하며, 월 단위 패치를 통해 코드 안정화를 진행합니다.
  4. PoW 채굴 노드 50~100대 확보 시 참여용 코인 배포 — 일정량의 PoW 채굴 노드가 확보되면, PoS 참여를 독려하기 위해 참여용 코인을 배포합니다.
  5. 노드 증가에 따른 자원 분산화 — 참여 노드가 늘어날수록 코인 자원이 분산되어 시장가치 왜곡이 줄어듭니다.
  6. 2026~2027년 개발 소스 순차적 GitHub 공개 — 단계별로 소스 코드를 오픈하여 누구나 검토/분석 및 코드 개발에 참여할 수 있도록 합니다.
  7. 소스 공개를 통한 참여자 확대 및 개발 주도권 분산 — 기존 개발 주체는 풀 리퀘스트 처리, 각종 테스트, 코드 검토 및 승인 등의 업무를 추가하며, 깃허브를 통해 모든 개발자에게 코드 기여 기회를 부여합니다.
  8. 가운영(준운영) 종료 — 코드 안정화와 충분한 노드 분산화를 달성한 후, 공식 운영 단계로 전환합니다.
  9. 완전한 분산 운영(Decentralization) 달성 — 운영 주체 없이도 네트워크가 자율적으로 유지/발전할 수 있는 구조를 완성합니다.
  10. 비트코인과 이더리움 등 선례를 참고해 지속 진화 — 모범적인 탈중앙화 생태계를 목표로, 참여자 모두가 합심하여 꾸준히 개선/진화합니다.

10. 부록 특허출원

특허출원문서 보기