많은 분들이 RC 시스템에 대해 의문도 제기하셨습니다. 한편 일부는 기대감도 보여주셨습니다. RC 시스템이 사용자 활동을 저해해서 생태계 성장을 망친다는 것이 의문의 주된 논지로 보이고, 스팀파워에 대한 수요를 올려서 스팀 가격을 높일 수 있다는 것이 기대의 이유입니다. 저는 양쪽 모두가 타당한 측면이 있다고 생각합니다. 하지만 여기서 말씀드리고 싶은 것은 RC 시스템이 왜 나왔는지에 대한 이유입니다.
RC시스템과 대역폭 시스템의 설계 원리는 크게 다르지 않습니다. 자원을 소모하는 만큼 비용을 내게 하자는 것이 둘의 공통적인 핵심입니다. 하지만 대역폭 시스템은 네트워크 대역폭에만 초점을 맞춘 반면, RC는 리소스를 조금 더 세분화해서 state 사이즈와 실행시간으로 나눴습니다.
과거 대역폭 모델에서는 일부 거래가 대역폭을 거의 사용하지 않는 현상이 있었는데 이를 이용한 스패밍도 꽤 존재했습니다. 예를 들자면 follow는 스팀파워가 거의 없어도 대량으로 거래를 생성할 수 있었습니다. 이 때문에 다른 스팀 활동에 소모되어야 할 블록 용량이 모자라기도 했습니다. RC 시스템 도입은 이러한 공짜 거래에 비용을 부과함으로써 불필요한 네트워크 자원 낭비를 줄이는 역할을 합니다.
하지만 보다 근본적인 변화가 하나 더 있습니다. 바로 RC 시스템이 컨센서스가 아니라는 점입니다. 즉, RC는 증인 노드가 자체적으로 거래를 포함시키지 않는 하나의 필터일 뿐, 블록체인 네트워크 차원에서 거래를 막는 시스템이 아닙니다. 이 방법의 단점이라면 누군가 악의적인 증인이 변조된 RC를 실행하면 그 증인을 통해 RC가 없어도 마구 거래를 생성할 수 있다는 것입니다. 하지만 이 방법은 금방 발견될 것이고 그 증인은 금방 내쫓길 것입니다.
컨센스서가 아닌 경우의 장점은 네트워크 자원이 덜 소요된다는 점입니다. 증인 노드 리플레이를 해보신 분은 아시겠지만 대역폭의 reserve ratio를 계산하는 데 상당한 시간이 필요합니다. 이 부분을 RC라는 플러그인으로 대체함으로써 스팀은 더 확장성을 가질 수 있습니다. 이는 향후 SMT로 가기 위한 중요한 포석이기도 합니다.
스팀은 앞으로 이렇게 기능들을 플러그인으로 모듈화하는 방식을 채택할 것입니다. 아마 RC 외에도 새롭고 유용한 플러그인이 더 생겨날 수도 있습니다. 아쉽게도 시작이 삐걱거렸지만 분명 RC 시스템은 스팀이 "확장"되는데 중요한 역할을 할 것입니다.
