filefilego
v1.4.3
FileFilego 프로토콜은 인센티브 메커니즘, 전체 텍스트 검색 및 스토리지 엔진을 갖춘 Web3 ERA를 위해 설계된 피어 투 피어 스토리지 및 데이터 공유 네트워크입니다. 분산 아키텍처를 통해 사용자는 검열이나 단일 실패 지점없이 데이터를 저장하고 공유 할 수 있습니다. FileFilego는 Game-Theory 개념을 활용하여 참여를 인센티브하고 데이터 가용성을 보장하면서 결함 불변성을 달성하고 개인 정보를 보존합니다.
FileFilego는 중앙 집중식 통제 또는 소유권이없는 오픈 소스 커뮤니티 프로젝트입니다. 코인 분포는 공정하게 설계되었으며 블록 당 40 ffg의 방출은 24 개월마다 절반으로 감소합니다. 이 프로토콜은 ICO/STO/IEO 또는 PRE-MINE없이 시작되며, 더 많은 이해 관계자가 참여할 수 있도록 지분 증명으로 전환 할 권한 증명서의 증명서 알고리즘에 의존합니다.
FileFilego를 지원함으로써 사용자는 디지털 권리, 개인 정보 보호, 정보의 자유 및 순 중립을 촉진 할 수 있습니다. 우리는 인터넷이 개방적이고 분산 된 플랫폼으로 유지되도록 기여와 혁신적인 아이디어를 장려합니다.
node_1 이 node_2 가 소유 한 일부 data_x 다운로드하고 node_2 에서 요구하는 수수료를 지불해야한다고 가정 해 봅시다. 비잔틴 결함 노드의 경우 어떻게됩니까? 대상 노드로의 성공적인 데이터 전송을 어떻게 확인하고 다음과 같은 악의적 인 경우를 방지합니까?
node_1 수수료 지불을 피하기 위해 data_x 유효하지 않은 것으로보고하는 부정직 한 노드입니다.node_2 data_y 에 node_1 제공하고 data_x 라고 주장하는 부정직 한 노드입니다. node_x 값 X를 방송 (피어 투 피어) 할 수 있고 다음을 만족하면 네트워크는 비잔틴 결함에 저항 할 수 있습니다.
node_x 정직한 노드 인 경우 모든 정직한 노드는 값 x에 동의합니다. 전송 메커니즘 증명은 네트워크의 정직한 노드가 node_2 에서 node_1 로 data_x 성공적으로 전송하는 것에 대한 합의를 확인하고 도달 할 수 있도록함으로써 위에서 언급 한 문제를 해결합니다. 이는 참여 노드에 도전하는 데 도움이되는 검증자를 사용하여 달성됩니다. 간단한 접근 방식에는 필요한 데이터를 검증기로 전송 한 다음 대상 노드로 전달하는 것이 포함되지만이 방법은 대역폭 및 스토리지 병목 현상으로 이어져 전체 네트워크 처리량을 줄일 수 있습니다. 따라서 전송 솔루션의 증명은이 프로세스와 관련된 대역폭 및 스토리지/메모리 요구 사항을 최소화하도록 설계되었습니다.
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
허락하다
파일의 내용을 나눕니다
세그먼트의 머클 트리 해시를 계산하십시오 : let
세그먼트를 셔플하십시오 : let
셔플 된 세그먼트의 1 %를 암호화합니다
암호화 된 세그먼트의 암호 해독 : 각각
셔플 순서 복원 : 암호화 과정에서 세그먼트가 섞여 있기 때문에 역 순열을 사용하여 원래 순서로 복원해야합니다.
Merkle Tree Hash 계산 : 복원 된 순서로 해독 된 세그먼트의 Merkle Tree 해시를 다시 계산합니다. 해시 트리를 원래 구조와 유사하게 구성하지만 해독 된 세그먼트를 사용하십시오.
마지막으로, 파생 된 원래 머클 루트 해시
파생 된 Merkle Root 해시가 원래 Merkle Root 해시와 일치하는 경우 합의가 이루어집니다.
후속 내용이 포함 된 파일과 관련된 시나리오를 고려하십시오.
FileFileGo_Network
스토리지 제공 업체에 파일을 업로드하면 파일의 머클 루트 해시가 컨텐츠를 별개의 데이터 세그먼트로 분할을 통해 계산합니다.
이어지는 그림은 저장 매체에 대한 파일 배열의 단순화 된 표현을 나타냅니다. 그림 내의 각 개별 상자는 1 바이트의 데이터를 상징합니다.
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
이 파일의 머클 루트 해시를 찾으려면 파일을 작은 부분으로 나눕니다. 예를 들어, 파일을 9 개의 섹션으로 분할하고 각 부분에는 2 바이트 만 있습니다.
0 1 2 3 4 5 6 7 8
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ F i │ l e │ F i │ l e │ G o │ _ N │ e t │ w o │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
이제 각 세그먼트의 해시를 가져옵니다.
segment 0: hash("Fi"), denoted by h0
segment 1: hash("le"), denoted by h1
segment 2: hash("Fi"), denoted by h2
segment 3: hash("le"), denoted by h3
segment 4: hash("Go"), denoted by h4
segment 5: hash("_N"), denoted by h5
segment 6: hash("et"), denoted by h6
segment 7: hash("wo"), denoted by h7
segment 8: hash("rk"), denoted by h8
그런 다음 알고리즘을 적용하여 파일의 머클 루트 해시를 계산합니다.
이 알고리즘이 어떻게 작동하는지에 대한 예는 다음과 같습니다.
┌───┬───┬───┬───┬───┬───┬───┬───┐
Data Blocks:│ a │ b │ c │ d │ e │ f │ g │ h │
└───┴───┴───┴───┴───┴───┴───┴───┘
0 1 2 3 4 5 6 7
│ │ │ │ │ │ │ │
└───┘ └───┘ └───┘ └───┘
h01 h23 h45 h67
│ │ │ │
└───────┘ └───────┘
h(h01+h23) h(h45+h67)
│ │
│ │
└───────────────┘
Merkle root: h(h(h01+h23)+h(h45+h67))
이제 우리는 MT (F)로 표시되는 파일에 대한 머클 루트 해시를 소유하고 있으며, 이는 본질적으로 또 다른 해시 값입니다.
데이터 검색 요청이 스토리지 제공 업체에 도달하면 공급자는 데이터 세그먼트를 임의의 순서로 재 배열합니다. 예를 들어, 데이터 세그먼트 순서를 고려하십시오.
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] .
1 5 2 4 7 6 3 0 8
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ G o │ w o │ e t │ l e │ F i │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
그 후, 제공자는 대칭 키 및 초기화 벡터 (iv)를 생성하여 이러한 세그먼트의 일부를 암호화합니다. 이 그림에서, 우리는 세그먼트의 25%를 암호화하는 것을 선택합니다. 또한, 우리는 4 개의 세그먼트마다 암호를 암호화하여 0 번째 및 4 번째 세그먼트를 암호화 할 것임을 암시합니다.
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
이제 위에서 언급 한 데이터가 데이터 요청자에게 제공됩니다. 동시에, 키/IV, 무작위 세그먼트 순서 및 세그먼트 0 및 4의 내용은 data verifier 로 전송됩니다. 다운로더는 파일 내 세그먼트 순서와 암호화 키/iv에 대해 Zero-Knowledge 가지고 있음을 강조하는 것이 중요합니다.
누군가가 원래의 순서를 결정하기 위해 다양한 세그먼트 조합을 시도하여 스크립트를 만들 가능성에 대해 우려 할 수 있으며, 잠재적으로 보안 취약성과 잠재적 공격으로 이어질 수 있습니다.
추가 통찰력을 제공하기 위해 실제 시나리오에서 파일이 대략 1024 세그먼트 (또는 약간 적음)로 나뉘어지고 이러한 세그먼트는 무작위로 나뉩니다. 공격자가 원래 세그먼트 순서를 재구성하려면 "반복없이 순열"을 수행해야합니다. 이 파일 세그먼트를 정리하는 총 방법은 n! (Factorial), 1024에 해당합니다! 이 경우. (https://coolconversion.com/math/factorial/what-is-pactorial-of_1024_%3f)
공격자의 후속 단계에는 두 세그먼트를 암호화하는 데 사용되는 키와 IV를 획득하려는 시도가 포함됩니다. 그러나이 작업은 현재 현장의 기존 취약점을 기반으로 불가능한 것으로 간주된다는 점에 주목할 가치가 있습니다.
이어서 파일 다운로더는 네트워크 내 지정된 data verifier 에서 암호화 키/IV와 파일 세그먼트의 무작위 순서를 요청해야합니다.
데이터 다운로더는 암호화 키/IV 및 무작위 세그먼트를 찾는 데이터 검증 자에게 요청을 보냅니다. 이 요청은 다운로드 된 파일의 세그먼트 해시가 수반되며 다음과 같이 표시됩니다.
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
data verifier 세그먼트 0 및 4에 대한 암호화 및 해싱을 수행하여 다음 해시 값을 초래합니다.
h1
h5
h2
h4
h7
h6
h3
h0
h8
마지막으로, data verifier 요청자에게 데이터 전송 중에 Hoster 파일에 의해 생성 된 무작위 순서에 따라 세그먼트를 재구성합니다. 이 프로세스는 원래 세그먼트 해시 시퀀스를 산출합니다.
h0
h1
h2
h3
h4
h5
h6
h7
h8
궁극적으로 Merkle Root 해시 계산의 실행을 통해 데이터 검증기는 전체 파일 컨텐츠에 대한 전체 로컬 액세스를 필요로하지 않고 원래 Merkle Root Hash를 추론합니다.
파생 된 머클 루트 해시가 원래의 것과 일치한다는 것을 확인하면, 우리는 데이터 다운로더가 요청 된 모든 데이터를 가지고 있다는 수학적 증거를 효과적으로 설정했습니다. 그 후, 데이터 검증자는 암호화 키/IV 및 무작위 세그먼트 순서를 데이터 다운로더로 전송하여 Hoster 파일에 대한 수수료의 자동 릴리스로 이어집니다.
이 섹션에서는 데이터 전송 검증의 전체 수명주기가 입증됩니다.
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Response 페이로드에는 스마트 계약 거래를 준비하는 데 필요한 모든 정보가 포함되어 있습니다. 그런 다음이 트랜잭션은 네트워크로 방송되어 검증자가 선택합니다. ┌──────────────────────────────────────┐
│ TRANSACTION │
├──────────────────────────────────────┤
│ Data : │
│ - Data query response │
│ - Remote node signature │
│ Value: │
│ - Fees required by node │
│ │
│ Fees : │
│ - Fees collected by verifier │
│ │
│ To : │
│ - Network verifier │
└──────────────────────────────────────┘
v1 )는 참여 노드와 통신하고 데이터를 호스팅하는 노드 ( node_2 )에 대한 도전을 생성합니다. 도전은 다음 단계로 구성됩니다.node_2 처음부터 업로드 된 data_x 의 원래 머클 루트와 일치하는 머클 트리를 생성해야합니다.v1 순서 와 node_2 로 node_1 로 전송 될 블록/데이터 범위의 수를 결정합니다. 우리는 아직 node_1 에 블록의 순서를 공개하고 싶지 않습니다.v1 node_2 고정 된 데이터 범위의 데이터를 요청하며 v1 의 랜덤 키 k1 data_enc 로 사용하여 node_1 로 전송됩니다. 이 단계에서 node_1 일부 data_z 및 data_enc 가지고 있지만 원본 파일을 얻기 위해이를 결합하는 방법에 대한 지식이 부족합니다. 검증 자 V1은 node_1 로 전송 된 데이터의 무결성을 확인할 수 있으며 원래 Merkle Tree의 ID와 일치하면 암호 해독 키 K1이 node_1 에 제공됩니다. 또한 블록 순서는 node_1 로 전송되어 모든 부품의 재 조립이 원래 데이터를 형성 할 수 있습니다. 이 프로세스가 완료되면 V1은 node_2 로 수수료를 공개합니다.
이 알고리즘을 사용하면 전송 증명 및 데이터 보유 증명의 동시 달성이 가능합니다.
지침에 따라 FileFilego를 컴파일하고 설치하십시오
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFilego는 블록 체인/cryptocurrency, DHT 및 Bittorrent의 혁신적인 기술의 견고성을 통합하여 분석 할 수없는 인프라를 형성하는 분산 된 네트워크입니다.
10 초의 블록 시간을 달성하려면 FileFilego에는 많은 양의 트랜잭션 처리에 효율적인 합의 알고리즘이 필요하며 처리 전력을 보존합니다. 초기 단계에서는 합의 알고리즘으로 권위 증명 (POA)을 선택했습니다. 향후, POS (Stake) 메커니즘은 현재 알고리즘을 대체 할 것입니다.
새로운 블록 체인에 POW 기반 알고리즘을 사용하면 이미 51%의 공격에 사용할 수있는 실질적인 컴퓨팅 전력 풀이 있기 때문에 위험이 있습니다. 따라서 우리는 설계별로 안전한 POA를 선택했으며 높은 거래량 요구 사항을 지원하는 데 필요한 효율성을 제공합니다.
유효성 검사기의 신원은 블록 체인으로 하드 코딩되며 Genesis Block의 Coinbase 트랜잭션을 조사하여 확인할 수 있습니다. 참여 노드는 블록의 서명을 확인하여 이러한 ID의 진위를 쉽게 확인할 수 있습니다.
앞으로 나아갈 때, 현재 POA 메커니즘은 여러 당사자가 블록 마이닝 프로세스에 참여할 수 있도록 스테이크 증명으로 대체됩니다. 블록 체인 거버넌스에 대한 우리의 목표는 더 많은 당사자와 개발자가 참여하고 이해 관계자 참여를 늘리도록 장려하는 것입니다. 이 목표를 달성하기위한 인센티브 중 하나는 스테이크 증명 메커니즘입니다.
거래 및 상태 돌연변이를 단순화하기 위해 FileFilego는 UTXO와 같은 구조와 다른 접근법을 채택합니다. 우리는 이러한 구조를 사용하는 대신 회계 및 메타 데이터를 일반 데이터베이스 행으로 저장하는 동시에 데이터베이스 내에서 원래 형식으로 원래 블록을 유지합니다. 이 접근법은 불필요한 복잡성을 제거하는 데 도움이됩니다.
이 섹션에서는 FileFilego에 사용되는 기술 용어 및 개념에 대한 개요를 제공합니다.
FileFilego의 채널을 통해 사용자는 데이터를 고유 한 버킷 또는 폴더로 구성하고 그룹화 할 수 있습니다. 예를 들어, ubuntu.com의 모든 콘텐츠는 "Ubuntu 공무원"이라는 채널에 배치 할 수 있습니다. 채널을 만드는 사용자는 업데이트 및 기타 채널 관련 작업에 필요한 모든 권한을받습니다.
채널은 노드 체인 형식으로 구성되며 ParentHash 없는 노드로 식별 될 수 있습니다.
하위 채널의 개념은 데이터를 더욱 분류 할 수 있어야합니다. 예를 들어, 문서, 사진 또는 음악.
FileFilego에서 Entry 분류/주문보다는 항목 자체에 대한 자세한 정보가 포함 된 게시물 또는 데이터를 나타냅니다. File 및 Directory Entry 에 배치 할 수 있습니다.
Storage Engine 은 이진 데이터를 추적하는 스토리지 레이어이며, 블록 체인 내의 해시 포인터가 데이터 조각을 참조하여 사용합니다. NodeItem 구조에는 이진 해시를 나타내는 FileHash 라는 필드가 있으며 "{HASH_ALGORITHM}:>{DATA_HASH}" 의 형태입니다. 우리는 미래에 유용 할 수 있으므로 해싱 알고리즘의 메타 데이터를 사용하고 싶습니다.
FileFilego에서 검색 정확도와 유연성은 핵심 블록 체인 기능과 마찬가지로 중요합니다. 우리는 사용자가 특정 쿼리 언어를 사용하여 이진 검색을 포함한 복잡한 쿼리를 구성 할 수 있도록합니다. 예를 들어 다음 유형의 쿼리가 가능해야합니다.
이러한 복잡한 쿼리를 지원하는 쿼리 언어를 개발하는 것은 검색 엔진의 정확도를 크게 향상시킬 수있는 강력한 도구입니다.
--search CLI 플래그를 사용하여 노드의 전체 텍스트 인덱싱 기능을 활성화 할 수도 있습니다.
스토리지 레이어는 이진 파일을 추적하고 해시를 사용하여 블록 체인 내에서 정보를 나타냅니다. 이 기능은 다음 플래그를 사용하여 켜질 수 있습니다.
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
--storage_dir 적절한 읽기/쓰기 권한이있는 디렉토리 여야합니다. 전체 노드는이 메커니즘없이 작동 할 수 있습니다. storage_token HTTP API를 사용하여 다른 토큰을 생성 할 수 있도록 토큰에 관리 권한을 부여하는 토큰입니다. 이는 웹 앱 또는 별개의 사용자가 Access Right가 필요할 때 유용하며 --storage_fees_byte="10000" 데이터 바이트 당 청구되는 수수료입니다.
| 단위 | 값 |
|---|---|
| ffgone | 1 |
| KFFG | 1.000 |
| MFFG | 1.000.000 |
| GFFG | 1.000.000.000 |
| 마이크로프 | 1.000.000.000.000 |
| Miliffg | 1.000.000.000.000.000 |
| FFG (기본 장치) | 1.000.000.000.000.000.000 |
| zffg | 1.000.000.000.000.000.000.000 |
총 공급 : 5 억 FFG 검증/스테이크 보상 : 블록 당 40 ffg 공급량 감소율 : 24 개월마다 2로 나뉩니다.
