노트 64: 인터넷 조정 시스템을 위한 최소 초기 사양, 현지화된 미래 결정, 자발적 채택

초록

이 문서에서는 시스템을 실행하는 참가자 위에 지속적인 권한을 생성하지 않고 공유된 기술 참조 지점을 제공하는 것이 목적인 인터넷 조정 시스템의 설계 패턴을 설명합니다. 이는 최소 초기 사양, 현지화된 향후 결정, 자발적 채택이라는 세 가지 연결된 원칙을 정의합니다.

이 모델에서 초기 사양은 고유성, 상호 운용성, 공유 안전 및 보안에 필요한 결정론적이고 로컬로 검증 가능한 규칙만 정의합니다. 초기 사양 이후 향후 변경 사항은 중앙 기관의 승인을 받지 않습니다. 코드를 실행하는 참가자는 이를 채택, 무시, 분기 또는 포기합니다.

채택하지 않는 것은 위반이 아닙니다. 이후 변경 사항을 채택하지 않은 참가자는 기존 호환성 집합에 남아 있습니다. 다른 참가자가 수락한 결정론적 규칙에 따라 유효하지 않은 상태를 내보내는 참가자는 해당 참가자에 의해 로컬로 무시될 수 있습니다. 효과는 제도적 처벌이 아닌 호환성 선택, 포크, 격리 또는 선택적 상호 운용입니다.

이 문서는 유선 프로토콜을 정의하지 않습니다. 이는 영구적인 거버넌스 기관이 되어서는 안되는 프로토콜, 레지스트리, 식별자 시스템 및 조정 메커니즘의 설계에 대한 현재 모범 사례를 지정합니다.

1. 소개

많은 인터넷 시스템은 공통 참조 지점, 식별자 공간, 유효성 검사 규칙 또는 레지스트리와 같은 기록을 공유하여 독립적인 행위자가 상호 운용될 수 있도록 하는 좁은 기술적 목적으로 시작됩니다. 시간이 지남에 따라 이러한 시스템은 초기 상호 운용성에 필요하지 않은 권한을 축적하는 경우가 많습니다.

이는 일반적으로 세 단계로 이루어집니다.

첫째, 향후 질문은 기술적으로 필요하기 전에 기초 계층에 배치됩니다.

둘째, 자체 시스템을 운영하는 참가자가 선택해야 하는 선택은 지속적인 기관의 인식, 해석 또는 상태 결정에 따라 달라집니다.

셋째, 참가자가 운영 시스템의 변경을 채택하지 않은 경우에도 출판, 등록, 권장 또는 절차적 승인은 운영 의무를 생성하기에 충분한 것으로 간주됩니다.

그 결과 시스템이 취약해졌습니다. 기술 참조 레이어는 거버넌스 레이어가 됩니다. 기록 보관인이 문지기가 됩니다. 조정 아티팩트는 향후 제어의 소스가 됩니다.

이 문서에서는 다른 디자인 분야를 제안합니다.

– 최소 초기 사양: 기본 상호 운용성, 고유성, 공유 안전 및 보안에 필요한 결정론적 공통 규칙만 지정합니다.
– 현지화된 미래 결정: 초기 사양 이후에는 참가자가 코드를 실행하면서 향후 선택 사항을 유지합니다. 참가자는 선택적으로 채택, 거부, 분기, 연결 해제 또는 상호 운용할 수 있습니다. 어떤 참가자도 상호 호환 가능한 규칙을 계속 실행하는 다른 참가자의 상호 운용성을 변경할 수 없습니다.
– 자발적인 채택: 코드를 실행하는 참가자의 구현, 운영, 검증 및 채택을 통해서만 나중에 변경 사항을 현실화할 수 있습니다.

이러한 원칙은 서로 연관되어 있습니다. 처음에 너무 많은 것을 지정하는 시스템은 향후 제어를 공통 계층에 미리 로드합니다. 지속적인 인식 계층을 떠나는 시스템은 배포 후 권한이 다시 나타날 수 있도록 허용합니다. 출판을 현실로 취급하는 시스템은 문서를 명령으로 변환합니다.

설계 직관은 간단합니다. 유효성은 참가자가 로컬에서 확인할 수 있는 결정론적 규칙에 따라 결정되어야 합니다. 참가자는 이후 변경 사항을 채택하거나 거부하거나, 분기하거나, 연결을 끊거나, 선택적으로 상호 운용할 수 있습니다. 기껏해야 호환성 세트에서 자체적으로 제거될 수 있습니다. 변경을 거부함으로써 상호 호환되는 코드를 계속 실행하는 다른 참가자의 상호 운용성을 깨뜨릴 수 없습니다.

이는 비트코인과 같은 시스템에서 볼 수 있는 것과 동일한 일반적인 교훈입니다. 합의 규칙은 그 위에 있는 기관이 아니라 검증 코드를 실행하는 사람들에 의해 시행됩니다.

2. 범위

이 문서는 공유 레지스트리, 식별자 시스템, 명명 및 번호 지정 프레임워크, 프로토콜 확장 메커니즘, 제어 증명 시스템, 이식성 시스템 및 독립 행위자가 공통 기술 참조 지점에 의존하는 기타 아키텍처를 포함하되 이에 국한되지 않는 인터넷 조정 시스템에 적용됩니다.

이 문서는 일반적인 규칙에 반대하지 않습니다. 이는 공통 규칙이 결정적이어야 하고, 최소화되어야 하며, 로컬에서 검증 가능해야 하며, 시스템이 실행되기 위해 실제로 필요한 것으로 제한되어야 한다고 주장합니다.

이 문서에는 블록체인, 분산 원장 또는 특정 기술이 필요하지 않습니다. 설계 속성이 필요합니다. 참가자는 상임 기관에 허가나 상태를 요청하지 않고 초기 사양을 로컬로 적용하여 유효성을 결정할 수 있어야 합니다.

3. 규약 및 정의

3.1. 요구사항 언어

이 문서에서 대문자로 표시된 요구 사항 용어는 BCP 14, 특히 RFC 2119 및 RFC 8174에 정의된 의미로 해석됩니다.

3.2. 용어

초기 사양:
시스템을 처음 배포하는 데 필요한 규칙, 데이터 구조, 형식, 불변성, 검증 절차 및 전환 규칙 세트입니다.

공통층:
독립적인 참가자가 상호 운용하는 데 필요한 최소 공유 규칙 세트 또는 참조 구조입니다. 공통 계층은 기관이 아닙니다. 참여자가 구현하고 검증하는 기술적 내용입니다.

결정론적 검증 규칙:
참가자가 로컬 계산이나 로컬 확인을 통해 상태, 레코드, 전환, 주장 또는 메시지가 지정된 규칙 세트에서 유효한지 여부를 결정할 수 있도록 하는 규칙입니다.

전역 불변성:
고유성, 기본 상호 운용성, 공유 안전 또는 보안을 유지하기 위해 호환성 집합 내에서 공통으로 유지되어야 하는 속성입니다.

참가자:
시스템을 실행, 확인, 배포 또는 의존하는 운영자, 구현, 노드, 네트워크, 조직 또는 기타 행위자입니다.

호환성 세트:
검증 규칙을 구현하여 상호 운용이 가능한 참가자 그룹입니다. 일부 참가자는 이를 채택하고 다른 참가자는 채택하지 않는 경우 나중에 변경하면 새로운 호환성 집합이 생성될 수 있습니다.

채택:
시스템을 실행하는 참가자의 실제 구현, 배포, 검증 및 사용입니다.

비채택:
제안된 변경 사항을 구현하거나 사용하지 않기로 한 참가자의 선택입니다. 비채택은 무효 상태를 생성하지 않습니다. 이는 참가자가 해당 변경 사항으로 생성된 호환성 집합에 참여하지 않았음을 의미할 뿐입니다.

국부적으로 거절:
실행되는 유효성 검사 규칙에 따라 유효하지 않거나 호환되지 않는 상태, 메시지, 기록 또는 전환을 무시, 거부 또는 상호 운용하지 않기로 한 참가자의 로컬 결정입니다.

포크:
둘 이상의 호환성 집합을 생성하는 유효성 검사 규칙 또는 운영 관행의 차이입니다.

조정 아티팩트:
참가자가 조정하는 데 도움이 되는 문서, 레지스트리 항목, 권장 사항, 구현 메모, 프로필, 참조 구현 또는 기타 아티팩트입니다. 조정 아티팩트는 참가자가 실행 중인 시스템에서 이를 채택하지 않는 한 구속력 있는 운영 현실을 생성하지 않습니다.

4. 문제 설명

디자이너는 기본 레이어에 너무 많은 내용을 입력하거나 미래의 질문을 해석하기 위해 계속적인 본문을 남겨두어 미래의 불확실성을 줄이려고 노력하는 경우가 많습니다. 이는 신중한 것으로 보입니다. 위험한 경우가 많습니다.

기초 계층의 과잉 사양에는 세 가지 비용이 발생합니다.

첫째, 미래의 선택을 변경이 더 어렵고 캡처가 더 큰 효과가 있는 공통 계층으로 이동합니다.

둘째, 기술적 타당성과 제도적 인정 사이에 모호성을 야기한다.

셋째, 기록을 유지하고 문서를 게시하거나 참가자를 소집하는 기관이 그러한 행위를 미래 현실에 대한 권위로 취급하도록 권장합니다.

배포 후에도 동일한 문제가 나타납니다. 시스템에서 변경 승인, 상태 결정 또는 일반적인 운영 해석을 위해 지속적인 기관이 필요한 경우 시스템은 창립 후 제어 계층을 만들었습니다. 해당 계층은 관리로 시작될 수 있습니다. 거버넌스가 될 수 있습니다. 그러면 그것은 질식 지점이 될 수 있습니다.

이 문서의 설계 목표는 더 나은 제도적 재량권이 아닙니다. 디자인 목표는 그러한 재량권이 필요하지 않도록 하는 것입니다.

잘 설계된 인터넷 조정 시스템은 처음부터 결정론적이고 지역적으로 검증 가능한 유효성 규칙을 정의해야 합니다. 공통 레이어 외부에 불변 선택 사항을 남겨 두어야 합니다. 참가자가 실행 중인 시스템에 자발적으로 채택한 경우에만 나중에 변경 사항이 현실화되도록 허용해야 합니다.

5. 원칙 1: 최소 초기 사양

5.1. 성명

초기 사양은 기본 상호 운용성, 고유성, 공유 안전 및 보안에 필요한 최소한의 결정론적 공통 규칙만 정의해야 합니다.

5.2. 요구사항

이 원리를 사용한 디자인:

1. 전역 불변성을 명시적으로 식별해야 합니다.
2. 각 전역 불변성에 대한 결정론적 검증 규칙을 정의해야 합니다.
3. 규칙이 명시된 전역 불변성을 유지하거나 첫 번째 배포를 활성화하는 데 필요하지 않은 한 초기 사양에 규칙을 배치해서는 안 됩니다.
4. 검증 규칙을 정책 선호도, 비즈니스 준비, 제도적 역할, 거버넌스 목표 및 재량적 판단과 분리해야 합니다.
5. 참가자가 기관, 등록 기관, 위원회, 정책 기관 또는 기타 당국에 묻지 않고 현지에서 일반 유효성을 확인할 수 있도록 허용해야 합니다.
6. 데이터 구조, 서명, 증명, 상태 전환 규칙, 충돌 규칙 또는 로컬 검증에 필요한 기타 메커니즘을 정의해야 합니다(SHOULD).
7. 향후 변형이 예측 가능한 경우 확장 신호, 버전 관리, 호환성 라벨링 또는 포크 식별을 정의해야 합니다.
8. 필요한 조정 아티팩트가 이식 가능하고 감사 가능하며 재현 가능하고 교체 가능하다는 것을 보장해야 합니다(MUST).
9. 주관적인 장점 판단보다 객관적인 기계 검증 조건을 선호해야 합니다.
10. 미래의 제도적 인정을 유효한 상태를 알거나 기록하거나 사용할 수 있는 유일한 경로로 만들어서는 안 됩니다.

5.3. 디자인의 의미

최소 초기 사양은 모호한 사양을 의미하지 않습니다. 이는 공통되어야 하는 것만 엄격하게 지정하는 것을 의미합니다.

시스템을 실행하려면 여전히 충분한 공통 구조가 필요합니다. 규율은 다음을 구별하는 것입니다.

– 고유성, 상호 운용성, 공유 안전 및 보안에 대한 공통 사항은 무엇입니까? 그리고
– 운영자 선호도, 비즈니스 관행, 배포 시기 또는 이후 채택 선택과 관련되어 공통 계층 외부에 남아 있을 수 있는 사항.

전역 불변성과 결정론적 검증 규칙을 명확하게 기술할 수 없는 설계는 너무 많은 재량권과 너무 적은 검증 가능한 내용을 지정했다고 가정해야 합니다.

6. 원칙 2: 지역화된 미래 결정

6.1. 성명서

초기 사양 이후 향후 결정은 코드를 실행하는 참가자에게 로컬로 유지되어야 합니다. 미래 결정은 참가자가 이를 채택한 호환성 집합에 대해서만 유효합니다. 이를 승인하는 데 지속적인 권한이 필요하지 않으며, 채택하지 않아도 무효 상태가 생성되지 않습니다.

6.2. 요구사항

이 원리를 사용한 디자인:

1. 참가자가 참여하는 호환성 세트의 결정론적 검증 규칙을 변경하지 않는 선택에 대해 기존 기관, 등록 기관, 위원회, 이사회, 정책 기관 또는 기타 권한으로부터 허가를 얻도록 참가자에게 요구해서는 안 됩니다.
2. 인식이 이후 변경 사항이 운영상 현실화될 수 있는 유일한 경로인 상설 기관을 생성해서는 안 됩니다.
3. 초기 사양에 따른 유효성과 이후 선택적 변경 사항의 호환성을 구별해야 합니다.
4. 이후 변경 사항을 채택하지 않는 것을 무효로 처리해서는 안 됩니다.
5. 참가자가 이후 변경 사항을 채택하지 않을 때 기존 호환성 세트를 유지하도록 허용해야 합니다.
6. 새로운 검증 규칙이나 운영 프로필을 채택하여 참가자가 새로운 호환성 세트에 참여할 수 있도록 허용해야 합니다.
7. 참가자가 실행하는 유효성 검사 규칙에 따라 유효하지 않거나 호환되지 않는 상태, 기록, 전환 또는 메시지를 로컬에서 거부할 수 있도록 허용해야 합니다.
8. 기관, 등록 기관, 위원회, 정책 기관 또는 기타 행위자가 단순히 향후 변경을 거부했다는 이유만으로 참가자를 무효로 선언하는 권한을 부여해서는 안 됩니다.
9. 참가자가 자신이 실행 중인 규칙과 상호 운용할 수 있는 다른 참가자를 알 수 있도록 포크, 버전, 프로필 또는 호환성 세트를 명시적으로 만들어야 합니다.
10. 현 기록 보관자가 유효한 참가자가 계속해서 상호 운용하는 것을 방해할 수 있는 설계는 피해야 합니다.

6.3. 디자인의 의미

지역화된 미래 결정은 중앙 당국이 미래 결정을 지역 행위자에게 할당한다는 의미는 아닙니다. 이는 초기 사양 이후 일반적인 미래 선택에는 그러한 할당이 필요하지 않도록 시스템이 설계되었음을 의미합니다.

초기 사양은 사전에 제한 작업을 수행합니다. 고유성, 상호 운용성, 공유 안전 및 보안에 필요한 최소 불변성을 정의합니다. 다른 모든 것은 공통 레이어 외부에 남아 있습니다.

향후 변경 사항은 중앙에서 승인되지 않습니다. 코드를 실행하는 참가자에 의해 채택, 무시, 분기 또는 폐기됩니다.

변경을 거부하는 참가자는 해당 변경으로 생성된 호환성 집합 외부에 남아 있을 수 있습니다. 다른 사람과의 연결이 끊어질 수 있습니다. 이전 호환성 세트에서 계속될 수 있습니다. 포크가 될 수 있습니다. 선택적으로 상호 운용될 수 있습니다. 그러나 상호 호환 가능한 규칙을 계속 실행하는 다른 참가자의 상호 운용성을 깨뜨릴 수는 없습니다.

유효하지 않거나 양립할 수 없는 상태의 효과는 처벌이 아니라 지역적 거부입니다. 누구도 참가자의 상태가 좋지 않다고 결정할 필요가 없습니다. 호환 가능한 유효성 검사 규칙을 실행하는 참가자는 유효하지 않거나 호환되지 않는 상태를 단순히 수락하지 않습니다.

7. 원칙 3: 자발적인 채택

7.1. 성명서

인터넷 조정 시스템의 변경 사항은 게시나 선언만으로 실행되는 것이 아니라 참가자의 구현, 검증, 배포 및 채택을 통해 운영상 현실화되어야 합니다.

7.2. 요구사항

이 원리를 사용한 디자인:

1. 공개, 등록, 추천, 회의 승인 또는 절차적 승인을 보편적인 운영 의무를 생성하기에 충분한 것으로 취급해서는 안 됩니다.
2. 새로운 규칙, 확장, 프로필 또는 절차를 실행하기로 선택한 참가자가 점진적으로 배포할 수 있도록 허용해야 합니다.
3. 참가자 자신의 상태 전환이 호환성 집합의 결정론적 유효성 검사 규칙을 충족하는 한, 참가자가 유효하지 않은 상태를 획득하지 않고 이후 변경을 거부할 수 있도록 허용해야 합니다.
4. 참가자가 초기 사양에서 이러한 연속성을 허용하는 이전 호환성 세트를 계속 사용할 수 있도록 허용해야 합니다.
5. 하나의 호환성 세트를 실행하는 참가자가 규칙이 호환되지 않는 다른 호환성 세트의 상태를 로컬에서 거부하거나 무시하도록 허용해야 합니다.
6. 버전 신호, 호환성 라벨링, 전환 지침 및 테스트 벡터를 포함하여 주요 변경 사항에 대한 채택 경로를 정의해야 합니다(SHOULD).
7. 채택하지 않은 참가자가 작업을 계속하는 방법, 호환성 세트를 식별하고 모호한 상호 운용을 방지하는 방법을 포함하여 주요 변경에 대한 거부 경로를 정의해야 합니다.
8. 불가능한 전환 비용 없이 필요한 조정 아티팩트를 종료, 이식, 미러링, 재구현 또는 교체할 수 있는지 확인해야 합니다.
9. 채택되지 않은 미래 현실이 존재한다고 선언하기보다는 채택된 현실을 설명하는 레지스트리, 기록, 권장 사항 및 조정 아티팩트가 있어야 합니다.
10. 변경이 현실화되는 유일한 방법은 현 기관의 사전 승인뿐인 시스템 설계를 피해야 합니다.

7.3. 디자인의 의미

자발적 채택은 변경 사항이 유용하고 허용 가능하며 실제 배포와 호환되는지 여부를 테스트하는 운영 테스트입니다.

제안은 현실이 아닙니다. 추천은 현실이 아닙니다. 레지스트리 업데이트는 현실이 아닙니다. 문서는 현실이 아닙니다. 참가자가 변경 사항을 구현, 검증, 배포 및 의존할 때 현실이 나타납니다.

비채택은 위반 상태를 생성하지 않습니다. 이는 단지 사실만을 생성합니다. 참가자는 변경으로 생성된 호환성 집합에 가입하지 않았습니다.

이는 표준 프로세스, 등록, 문서화 또는 검토를 제거하지 않습니다. 그것은 그들의 주장을 제한합니다. 참가자들이 조정하는 데 도움이 될 수 있습니다. 참고 자료를 출판할 수도 있습니다. 입양을 설명할 수도 있습니다. 그들은 추천할 수도 있습니다. 선언만으로는 채택되지 않은 미래 현실을 실행하지 않는 참가자에게 구속력을 부여할 수 없습니다.

8. 세 가지 원칙의 관계

세 가지 원칙은 서로 강화되며 단독으로는 효과적이지 않습니다.

최소 초기 사양은 공통 계층에 임의 권한이 아닌 결정론적 유효성 검사 규칙이 포함되도록 보장합니다.

지역화된 미래 결정은 중앙 승인 계층에 의해 다시 포착되지 않고 참가자가 코드를 실행하면서 미래의 선택이 유지되도록 보장합니다.

자발적인 채택은 이후의 변경 사항이 구현 및 사용 시에도 살아남아야 함을 보장합니다.

이러한 원칙 중 한두 가지만 채택하는 시스템은 다른 수단을 통해 동일한 중앙 집중화를 재현할 수 있습니다.

– 현지화된 향후 결정이 없는 최소 초기 사양은 배포 후에도 권한이 누적되도록 허용할 수 있습니다.
– 최소 초기 사양 없이 지역화된 미래 결정은 참가자가 지역적으로 유효성을 결정할 수 없기 때문에 모호성을 초래할 수 있습니다.
– 결정론적 검증 없이 자발적으로 채택하면 참가자가 호환 가능한 변형과 ​​유효하지 않은 상태를 구별할 수 없기 때문에 혼란을 초래할 수 있습니다.
– 종료, 이식성 또는 교체 가능성이 없는 결정적 검증은 기록 보관 아티팩트를 남길 수 없게 되는 경우 여전히 잠금을 생성할 수 있습니다.

이 원칙들은 함께 공통 계층이 얇고 타당성이 로컬로 검증 가능하며 향후 변경이 자발적이며 일반 운영을 결정하는 데 상설 기관이 필요하지 않은 시스템을 생성합니다.

9. 추천 디자인 패턴

9.1. 결정적 공통 계층

공통 레이어는 다음으로 제한되어야 합니다.

- 안정적인 식별자 의미론;
– 결정론적 타당성 규칙;
– 고유성을 보존하는 데 필요한 갈등 해결 규칙
– 와이어 수준 또는 프로토콜 수준의 상호 운용성 요구 사항
– 공유 보안 불변성;
- 필요한 경우 통제 증명 메커니즘
– 기록이 필요한 경우 휴대 가능하고 감사 가능한 기록 형식
– 확장 신호 및 호환성 집합 식별.

공통 레이어에는 다음이 포함되어서는 안 됩니다.

– 비즈니스 모델 규칙;
– 가격 책정 규칙;
– 지역적 정치적 선호;
– 기술적 불변성과 관련되지 않은 자격 이데올로기;
– 재량적 집행 권한;
– 주관적인 장점 평가;
– 기관적 임무 확장;
– 기존 기관의 권위를 보존하는 것이 주요 기능인 모든 규칙.

9.2. 운영자 결정 표면

다음은 명시된 전역 불변성을 직접 변경하지 않는 한 공통 계층 외부에 남아 있어야 합니다.

– 배포 시기
– 상업적 사용;
– 고객 지역;
– 임대, 융자 또는 양도 계약;
– 현지 자격 우선권;
– 운영 순서;
– 공유 유효성을 위해 라우팅 관행이 필요하지 않습니다.
– 비즈니스 모델;
– 조직 구조
– 자발적 이주 시기;
– 선택적 프로필 또는 확장.

참가자는 이러한 영역에서 다양한 선택을 채택할 수 있습니다. 이러한 선택에 따라 다양한 호환성 집합, 비즈니스 관계, 피어링 계약 또는 운영 커뮤니티가 생성될 수 있습니다. 호환성 집합의 결정적 유효성 검사 규칙을 위반하지 않는 한 무효성을 생성하지 않습니다.

9.3. 채택 루프

가능한 경우 재료 시스템 변경에 대한 선호 순서는 다음과 같습니다.

1. 제안서
2. 구현
3. 테스트 벡터 또는 결정론적 검증 방법
4. 자발적인 참가자에 의한 제한된 배포;
5. 상호 운용성 및 보안 효과의 관찰
6. 적합성 설정 표시
7. 채택된 현실을 설명하는 문서 또는 권장 사항.

조정 아티팩트는 선점을 시도하기보다는 채택을 따라야 합니다.

9.4. 종료, 포크 및 이식성

적합한 디자인은 종료, 분기 및 이식성을 실패가 아닌 일반적인 디자인 요구 사항으로 처리해야 합니다.

시스템은 참가자가 다음을 수행할 수 있는 방법을 정의해야 합니다.

– 이전 호환성 세트를 계속 사용합니다.
– 최신 호환성 세트를 채택합니다.
– 다른 호환성 세트로 분기합니다.
– 항만 기록, 식별자, 증명 또는 운영 상태;
– 현 기록 보관인에게 의존하지 않고 기록의 유효성을 확인합니다.
– 호환성이 허용되는 경우 선택적으로 상호 운용됩니다.

유효한 운영을 파괴하지 않고 종료하거나 분기할 수 없는 시스템은 아마도 기록 보관 기능 내에 숨겨진 거버넌스 권한을 가지고 있을 것입니다.

10. 적용 범위 및 한계

이 디자인 패턴은 특히 다음과 같은 경우에 적용 가능합니다.

– 시스템은 다중 행위자 및 다중 관할권을 갖고 있습니다.
– 독립적인 배포 문제;
– 조정 레이어는 얇게 유지되도록 고안되었습니다.
– 미래의 변동이 있을 가능성이 높지만 자세히 예측할 수는 없습니다.
– 종속은 거버넌스 위험을 야기합니다.
– 타당성은 결정론적이거나 지역적으로 검증 가능하도록 만들어질 수 있습니다.

다음과 같은 경우에는 덜 직접적으로 적용 가능합니다.

– 단일 관리 도메인이 의도된 아키텍처입니다.
– 강력한 실시간 결합은 항상 균일한 동작을 요구합니다.
– 생명 안전 문제는 즉각적인 전 세계적 통일성을 요구합니다.
– 타당성은 실제 메커니즘으로 로컬에서 확인할 수 없습니다.

이러한 경우에도 설계자는 공통 계층을 최소화해야 하며 가능하면 향후 임의 제어를 피해야 합니다.

11. 논골

이 문서는 다음을 수행하지 않습니다.

– 모든 조정을 금지합니다.
– 모든 공유 레지스트리를 금지합니다.
– 블록체인 또는 분산 원장 기술이 필요합니다.
– 합의를 보장합니다.
– 정치적 중립성을 보장합니다.
– 모든 참가자가 이후의 모든 변경 사항을 채택하도록 요구합니다.
– 입양 거부를 무효로 간주합니다.
– 호환성을 주장하면서 호환되지 않는 로컬 동작을 합법화합니다.
– 보안에 중요한 공통 규칙이 필요하지 않습니다.

12. 보안 고려 사항

더 얇은 조정 레이어는 포획 위험을 줄이고 제도적 오류의 폭발 반경을 낮추며 교체 가능성을 향상시킬 수 있습니다. 그러나 현지 재량권이 증가하면 일관되지 않은 보안 상태, 다운그레이드 경로, 조각화 압력, 모호한 호환성 주장 및 안전하지 않은 포크가 발생할 수도 있습니다.

따라서 이 문서를 적용하는 디자이너는 보안 불변성을 명시적으로 지정해야 합니다. 특히:

– 공유 유효성에 필요한 인증 및 권한 부여 요구 사항은 결정적이어야 하며 로컬에서 검증 가능해야 합니다.
– 버전 협상 및 확장 처리는 보안이 영향을 받는 경우 자동 다운그레이드를 피해야 합니다.
– 남용 및 서비스 거부 위험에 대해 거부, 분기 및 교체 경로를 분석해야 합니다.
– 호환성 레이블은 호환되지 않는 규칙 세트 간의 우발적인 상호 운용을 방지할 수 있을 만큼 충분히 명확해야 합니다.
– 로컬 변형은 자신이 만족하지 않는 규칙 세트와의 호환성을 거짓으로 주장하도록 허용되어서는 안 됩니다.

보안 예외가 존재한다고 해서 일반 권한 계층이 정당화되는 것은 아닙니다. 이는 명시된 전역 불변성을 보존하는 데 필요한 결정론적 보안 규칙만을 정당화합니다.

13. IANA 고려 사항

이 문서에는 IANA 작업이 없습니다.

14. 참고자료

14.1. 규범적 참고자료

– RFC 2119 — 브래드너, S., 요구 사항 수준을 나타내기 위해 RFC에서 사용되는 키워드, BCP 14, RFC 2119.
– RFC 8174 — 레이바, B., RFC 2119 핵심 단어에서 대문자와 소문자의 모호함, BCP 14, RFC 8174.

14.2. 유익한 참고 자료

– RFC 6709 — Carpenter, B. 및 B. Aboba, 프로토콜 확장을 위한 설계 고려 사항, RFC 6709.
– RFC 7282 – Resnick, P., IETF의 합의 및 허밍에 대하여, RFC 7282.

부록 A. 설계 체크리스트

이 문서에 대한 적합성을 주장하는 디자인은 다음 질문에 명확하게 대답할 수 있어야 합니다.

1. 전역 불변성이란 무엇입니까?
2. 전역 불변성을 보존하는 결정론적 검증 규칙은 무엇입니까?
3. 초기 사양의 어떤 규칙이 최초 배포에 반드시 필요한가요?
4. 공통 레이어 외부에 의도적으로 남겨둔 미래 질문은 무엇입니까?
5. 참가자가 속한 호환성 세트를 변경하지 않고 향후 어떤 선택을 할 수 있습니까?
6. 참가자는 이후 변경 사항을 어떻게 채택합니까?
7. 참가자가 유효하지 않은 상태를 할당받지 않고 이후 변경을 어떻게 거부합니까?
8. 호환성 세트는 어떻게 레이블 지정되거나 검색됩니까?
9. 참가자가 실행하는 규칙에 따라 상태가 유효하지 않거나 호환되지 않는 경우 로컬 거부는 어떻게 작동합니까?
10. 포크패스란 무엇인가요?
11. 이식성 경로는 무엇입니까?
12. 필요한 조정 아티팩트의 종료 경로는 무엇입니까?
13. 참가자는 현 기록 보관자에게 의존하지 않고 일반적인 유효성을 확인할 수 있습니까?
14. 기록 및 조정 인공물은 채택된 현실을 설명합니까, 아니면 채택되지 않은 미래 현실이 존재하도록 선언하려고 시도합니까?
15. 시스템이 공통 계층에 포함된 의사결정 수를 최소화했습니까?
16. 시스템이 일반 참가자 상태를 결정하는 지속적인 권한을 회피했습니까?

## 저자 주소

H. 루
[TBD]