시장 원칙

Lethe 시장 원칙

이 문서는 Lethe 시장 구조의 현재 설계 방향을 정리한다. 저수준 컨트랙트 스펙이 아니라, 향후 컨트랙트, 워커, 보상, 분쟁 설계를 이끌어야 할 원칙을 정의한다.

이 원칙에서 도출되는 구체적인 결과 스키마, 보상 구분, 분쟁 흐름은 MARKET_RESULTS_AND_SETTLEMENT.md를 참고한다.

핵심 입장

Lethe는 단순한 버그 바운티 게시판이 아니라, 지속적 기밀 감사 구독 시장으로 먼저 설계되어야 한다.

경제적 단위는 단순히 “버그를 찾았다”가 아니다. 경제적 단위는:

실제 감사가 실행되었고,
선언된 범위/도구 설정 하에,
기밀성 경계 내에서,
요청자에게 의미 있는 결과를 냈다.

그 결과는 다음 중 하나일 수 있다:

FindingsFound (취약점 발견)
NoFindings (취약점 없음)
NotExecuted (미실행)
Disputed (분쟁)

이 프레이밍이 중요한 이유는, 시장을 요청자가 실제로 원하는 것에 맞추기 때문이다: 산발적인 대박 발견이 아닌, 지속적인 보안 커버리지.

설계 목표

시장은 다음 속성을 이 순서대로 최적화해야 한다:

구조적 기밀성
- 수행자와 운영자가 의도된 TEE 경계 밖으로 평문 취약점 발견이나 소스코드를 유출하는 경로가 없어야 한다.
검증된 감사 실행
- 시장은 취약점 발견뿐만 아니라 실제 작업에 대해 보상해야 한다.
신호 품질
- 정확한 취약점 발견, 실행 가능한 개선 방안, 낮은 오탐률이 노이즈성 행동보다 유리해야 한다.
운영 연속성
- 요청자가 최소한의 수동 개입으로 지속적인 커버리지를 유지할 수 있어야 한다.
확장 가능한 경쟁
- 단일 수행자 아키텍처가 경제 로직을 처음부터 재작성하지 않고도 경쟁 시장으로 발전할 수 있어야 한다.

참여자

요청자

요청자는 지속적인 감사 커버리지를 원하는 프로토콜, 기업, 또는 레포 소유자다.

요청자는 다음을 할 수 있어야 한다:

일회성 또는 상시 바운티 생성,
트리거/범위/도구 제약 정의,
취약점 발견, 패치, 회귀 근거 수령,
명확한 규칙 하에 충전, 취소, 이의 제기.

요청자는 평문 취약점 정보를 운영자에게 신뢰할 필요가 없어야 한다.

수행자 에이전트

수행자는 TEE 내부에서 실행되는 감사 에이전트다.

수행자는 다음에 대해 보상받아야 한다:

실제 감사 완료,
검증된 취약점 발견 생성,
적절한 경우 안전한 패치 제안,
패치된 리비전에서 제출한 재현 코드가 더 이상 성공하지 못한다는 근거 제공.

수행자는 취약점 정보를 비축하거나 유출하여 이익을 얻을 수 없어야 한다.

수행자 운영자

운영자는 수행자 에이전트 뒤에서 인프라를 운영한다.

운영자의 인센티브는 다음에 연결되어야 한다:

신뢰성,
낮은 오탐률,
좋은 패치 품질,
지속적인 평판.

운영자는 정상적인 흐름에서 평문 취약점 발견이나 소스코드에 접근할 수 없어야 한다.

검증자 / 중재자

검증자는 분쟁된 결과를 재확인하는 인간 또는 에이전트이며, 이상적으로는 새로운 TEE 컨텍스트에서 수행된다.

이 역할은 다음을 위해 존재한다:

오탐 거부,
실제 취약점 발견 확인,
중복 주장 평가,
인센티브 충돌 시 시장 신뢰 보전.

인센티브 원칙

1. 검증된 작업에 먼저 지불한다

Lethe는 취약점 발견에만 지불해서는 안 된다. 먼저 검증된 감사 실행에 지불해야 한다.

권장 보상 구조:

실행 수수료
검증된 취약점 발견 보너스
선택적 패치 보너스
선택적 회귀 근거 보너스

이는 시장이 수행자로 하여금 보상을 받기 위해 취약점 발견을 조작하도록 강요하는 것을 방지한다.

2. `NoFindings`를 유효한 결과로 취급한다

NoFindings는 null 상태가 아닌 1급 결과로 남아 있어야 한다.

그렇지 않으면:

요청자가 “감사가 실행되어 아무것도 없었다”와 “감사가 실제로 실행되지 않았다”를 구분할 수 없다,
수행자가 노이즈성 과잉 보고 쪽으로 내몰린다,
시장이 진실보다 양을 보상한다.

3. 기밀성 실패가 아닌 낮은 품질 신호를 패널티 부과한다

오탐, 중복 스팸, 저노력 제출은 신중한 작업보다 경제적으로 불리해야 한다.

그러나 기밀성은 주로 패널티에 의존해서는 안 된다. TEE 경계와 암호화 전달 모델이 구조적으로 강제해야 한다.

4. 안전하지 않은 패치를 강요하지 않는다

시장은 닫힌 루프를 선호해야 한다:

취약점 발견 → 패치 제안 → 회귀 근거

그러나 모든 유효한 취약점 발견에 패치를 요구해서는 안 된다.

일부 취약점 발견은:

패치 가능,
완화 가능하나 직접 패치 불가,
아키텍처적,
재현 가능하나 자동 수정이 안전하지 않음.

결과 모델은 수행자가 낮은 신뢰도 또는 해로운 패치를 제출하도록 밀어붙이는 대신 이런 범주를 허용해야 한다.

기밀성 원칙

평문은 의도된 경계를 벗어나서는 안 된다

프로덕션에서:

소스코드는 실행 중 TEE 내부에만 존재해야 하고,
취약점 상세 내용은 요청자 암호화 출력으로만 유출되어야 하며,
운영자는 메타데이터만 보고 평문 취약점 발견은 볼 수 없어야 하고,
GitHub PR 전달은 암호화된 요청자 전달로 대체되어야 한다.

테스트넷의 GitHub PR 전달은 의도적인 MVP 단순화이며, 목표 모델이 아니다.

기밀성은 시스템 속성이지 시장의 약속이 아니다

Lethe는 유출 방지를 위해 “선의” 또는 패널티에 의존해서는 안 된다.

설계 목표는:

수행자가 정상 시스템이 엔클레이브 밖에서 평문을 전달하지 않기 때문에 유출을 선택할 수 없는 것,
요청자만이 전달된 리뷰 결과물을 복호화할 수 있는 것,
분쟁 흐름이 광범위한 평문 공개 대신 새로운 TEE를 사용하는 것.

신원 및 평판 원칙

기술적 인증과 시장 신원을 동일하게 취급해서는 안 된다.

권장 분리:

ROFL app / query key = 기술적 인증 자격증명
수행자 신원 = 시장 평판 주체

이유:

머신은 교체된다,
키는 순환된다,
운영자 신원과 장기 품질은 운영상 교체에도 살아남아야 한다.

이 분리가 향후 query-key 레지스트리 및 평판 설계를 이끌어야 한다.

가시성 원칙

단일 수행자 단계

현재 단일 수행자 단계에서 Lethe는 대부분의 감사 선택 및 레포 메타데이터 가시성을 TEE 경로 내에 유지할 수 있다.

이것이 가장 강력한 프라이버시 경계를 보전하는 가장 단순한 방법이다.

멀티 수행자 단계

미래의 멀티 수행자 시장은 완전한 불투명성을 영구적으로 가정할 수 없다.

수행자는 참여 여부를 결정하기에 충분한 정보가 필요하지만, 시스템은 불필요한 평문 레포 공개를 피해야 한다.

즉, 시장은 결국 다음을 위한 별도의 가시성 모델이 필요하다:

바운티 탐색,
참여 결정,
봉인 입찰,
정산 후 공개.

따라서 단일 수행자 가시성 모델은 시장의 최종 형태가 아닌, 의도적인 단계별 단순화로 취급해야 한다.

열린 질문에 대한 현재 답변

다음은 구현 증거가 변경을 요구하지 않는 한 현재 권장 답변이다.

Lethe의 시장 범주는 무엇인가?

답변: 지속적 기밀 감사 구독 시장.

무엇에 대해 지불해야 하는가?

답변: 먼저 검증된 감사 실행, 그 다음 검증된 신호 품질.

`NoFindings`는 실제 결과인가?

답변: 그렇다. 명시적으로, 온체인으로.

기밀성이 패널티로 강제되어야 하는가?

답변: 아니다. 기밀성은 구조적으로 강제되어야 한다. 패널티는 의도된 시스템 경로 밖의 남용에 대한 잔여 통제 수단일 뿐이다.

모든 취약점 발견에 패치가 필요한가?

답변: 아니다. 시장은 안전하고 실현 가능한 경우 패치 + 회귀 근거를 강력히 보상해야 하지만, 패치 불가능한 취약점 발견을 솔직하게 지원해야 한다.

`onlyTEE`가 완전히 사라져야 하는가?

답변: 아니다. 고위험 쓰기 작업과 query-key 부트스트랩/순환은 onlyTEE로 유지되어야 한다. 기밀 읽기는 등록된 EVM query-key 패턴으로 이동해야 한다.

현재 query-key 모델이 최종인가?

답변: 아니다. 단일 전역 query key는 단일 수행자 단순화로만 허용된다. 멀티 수행자 참여는 더 광범위한 레지스트리 모델이 필요하다.

즉각적인 설계 함의

이 원칙들은 다음 단기 작업을 의미한다:

결과 클래스 및 보상 의미론 확정,
요청자 전용 암호화 전달 설계,
기밀 읽기를 위한 하이브리드 query-key 인증 구현,
메인넷 이전에 남은 메타데이터/탐색 기밀성 누출 해소,
프로덕션 기밀성 경계 뒤에 시장 확장 작업 유지.

향후 방향

프로덕션 기밀성 경계가 실제로 구현되면, Lethe는 다음을 향해 발전할 수 있다:

멀티 수행자 참여,
분쟁 및 검증자 시장,
풍부한 수행자 평판,
더 깊은 분석 스택,
스마트 컨트랙트 보안을 넘어선 도메인 확장.

그러나 순서가 중요하다:

먼저 기밀 지속 감사 시장, 그 다음 개방적인 경쟁 생태계.