RippleMessenger: 블록체인 기반 클라이언트 (part 1/2)

Source: Dev.to

(번역을 진행하려면 번역하고자 하는 본문 텍스트를 제공해 주세요.)

Question

개인 데이터 권리에 대한 이전 분석을 바탕으로, 개인이 사이버 공간에서 최대한의 공정성과 자유를 달성할 수 있는 정도는 어느 정도일까요?

개인용 컴퓨터에 대한 주권

자신의 컴퓨터(사이버 공간의 일부이기도 함)를 사용할 때, 개인은 거의 주권을 가집니다:

• 원하는 데이터를 언제든지 저장할 수 있습니다.
• 원하는 때에 데이터를 읽을 수 있습니다.
• 원하는 때에 데이터를 삭제할 수 있습니다.
• 새로운 콘텐츠를 생성할 수 있습니다(소설을 쓰고, 영상을 편집하고, 디자인 작업을 수행).
• 원하는 소프트웨어를 설치할 수 있습니다(직접 작성한 소프트웨어도 포함).
• 기계를 켜거나 끌 수 있고, 네트워크에 연결하거나 연결을 끊을 수 있습니다.

즉, 개인용 컴퓨터를 사용할 때, 개인이 주인공입니다.

따라서: 컴퓨터를 더 자주 사용하세요. 자신의 컴퓨터를 사용할 때, 여러분은 통제권을 가지고 있습니다.

현실적인 최대 권한 vs. 온라인 서비스

자신이 통제하지 않는 온라인 서비스를 상대할 때 개인이 현실적으로 추구할 수 있는 가장 큰 권한은 자신이 공개한 데이터가 삭제되지 않을 권리입니다.

이를 달성하기 위해서는 다음 세 가지 조건을 충족해야 합니다:

1. 로컬 저장 및 백업

   • 데이터를 개인용 컴퓨터에 보관합니다.
   • 네트워크 서비스가 데이터를 삭제하더라도, 로컬 사본을 다시 업로드하고 재공개할 수 있습니다.

2. 열린, 독립적이며 공개된 데이터 형식

   • 데이터를 공개적으로 명시된 형식으로, 어떠한 독점적 조건에도 얽매이지 않게 게시합니다.
   • 예시: TCP/IP 패킷 표준이 공개되면, 표준에 부합하는 모든 패킷은 인터넷을 통해 전송될 수 있습니다.
   • 데이터는 특정 시스템과 무관하게 존재할 수 있으며, 시스템은 단지 개인의 지시에 따라 데이터를 전송·저장·표시할 뿐입니다.
   • 따라서 누구든 사이버 공간에서 데이터 서비스를 제공할 수 있으며, 단일 제공자가 전체 네트워크에서 개인의 공개 데이터를 삭제할 수 없습니다.

3. 위조 방지 및 부인 방지 데이터(암호학적 무결성)

   • 데이터를 암호화 서명합니다. 유효한 서명은 위조를 방지하고 서명자가 해당 데이터를 공개했음을 부인할 수 없게 합니다.
   • 키 쌍은 공개 알고리즘을 사용해 로컬에서 생성되며, 제3자에 의해 권한 부여되거나 관리되지 않으므로 익명 게시가 가능합니다(서비스 제공자와 상호작용하지 않는 제3자에 대한 익명성).
   • 개인은 필요에 따라 특정 당사자에게 실제 신원을 밝히거나 밝히지 않을 수 있습니다. 신뢰는 궁극적으로 각 구체적인 사람의 판단에 달려 있습니다.

위에서 설명한 두 가지 주요 권한 외에, 개인이 추가적인 권리를 추구할 필요는 없으며, 오히려 다른 요구를 적극적으로 포기하는 것을 고려해도 됩니다.

권장 데이터 형식

분석을 기반으로, 개인은 사이버 공간에 데이터를 게시하기 위해 하나의 데이터 형식을 선택해야 합니다. 형식은 아래에 정의되어 있습니다.

{
  "type": "object",
  "required": [
    "ObjectType",
    "Sequence",
    "PreHash",
    "Content",
    "Timestamp",
    "PublicKey",
    "Signature"
  ],
  "maxProperties": 10,
  "properties": {
    "ObjectType": { "type": "number", "const": "ObjectType.Bulletin" },
    "Sequence":   { "type": "number" },
    "PreHash":    { "type": "string" },
    "Content":    { "type": "string" },

    "Tag": {
      "type": "array",
      "minItems": 1,
      "items": { "type": "string" }
    },

    "Quote": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["Address", "Sequence", "Hash"],
        "properties": {
          "Address":  { "type": "string" },
          "Sequence": { "type": "number" },
          "Hash":     { "type": "string" }
        }
      }
    },

    "File": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["Name", "Ext", "Size", "Hash"],
        "properties": {
          "Name": { "type": "string" },
          "Ext":  { "type": "string" },
          "Size": { "type": "number" },
          "Hash": { "type": "string" }
        }
      }
    },

    "Timestamp": { "type": "number" },
    "PublicKey": { "type": "string" },
    "Signature": { "type": "string" }
  }
}

필드 설명

핵심 / 필수 필드 (6)

내용 관련 필드 (선택 / 확장 가능)

게시판 개요

게시판 자체에는 파일 데이터가 포함되지 않으며 — 해시를 통해 참조만 보관하여 실제 파일을 별도로 전송할 수 있습니다.

최소 검증 규칙

어떤 노드/피어든 게시물을 수락하거나 저장하기 전에 다음 검사를 수행해야 합니다:

1. 서명 검증

   • 제공된 PublicKey를 사용하여 Signature를 검증합니다.
   • 이는 발행자의 무결성과 진위성을 확인합니다.

2. 시퀀스 연속성

   • 체인에서 현재 마지막 시퀀스 번호(PublicKey + ObjectType에 대해)가 정확히 **Sequence - 1**인지 확인합니다.

3. Pre‑hash 검증

   • 이전 항목(Sequence - 1)의 해시를 계산합니다.
   • 계산된 해시가 게시물의 PreHash 필드와 일치하는지 확인합니다.
   • 이는 새 항목을 체인의 끝에 추가할 수 있음을 보장합니다.