Isolate sensitive parts of Libplanet related to state transition logic into Libplanet.Abstractions project.

[moreal]

This is a proposal to create a new project called Libplanet.Abstractions. I am working on a feature called Pluggable Lib9c in the planetarium/NineChronicles.Headless project. The goal of the Pluggable Lib9c feature is to leverage .NET's DLL dynamic loading capabilities to reduce the implementation headaches that Lib9c has had to deal with. This will allow Lib9c to hold only one hack_and_slash each time, instead of holding a bunch of state transition logic like hack_and_slash2, hack_and_slash3, and hack_and_slash4, and help solve the complexity by dynamically loading DLLs based on block index segments.

However, this would mean that each version of Lib9c would have its own DLL, and binding to types such as IAction and IAccountStateDelta would be done at runtime when dynamically loading and casting, and if the IAction in Libplanet used by planetarium/NineChronicles.Headless is incompatible with the IAction in Libplanet used when the original Lib9c was built, this would not work.

To give an example of an incompatible case, suppose you have an IAccountStateDelta and an IAction like the following.

interface IAccountStateDelta {
  IValue GetState();
}

interface IAction {
  IAccountStateDelta Execute(IActionContext context);
}

And let's say you have an Action that implements the above IAction. If you later modify Libplanet and add a feature to IAccountStateDelta that changes the signature, it will fail to cast at runtime because it is a different IAccountStateDelta than the one the original Action promised to return.

The purpose of splitting Libplanet.Abstractions into projects is twofold.

• To explicitly separate the things that should be changed from the things that shouldn't be changed.
• Minimize what planetarium/lib9c and planetarium/NineChronicles.Headless share with each other and allow them to have different Libplanet implementations. Makes it easier to make changes in Libplanet, except where it affects state transition logic by type.

Translated with www.DeepL.com/Translator (free version)

한국어 원어

이 글은 Libplanet.Abstractions 라는 새로운 프로젝트를 만드는 것과 관련한 제안입니다. 저는 planetarium/NineChronicles.Headless 프로젝트에서 Pluggable Lib9c 라는 기능을 작업하고 있습니다. Pluggable Lib9c 기능은 .NET의 DLL 동적 로딩 기능을 활용하여 Lib9c가 지금까지 짊어왔던 구현 복장섭을 낮춰주는데 목표가 있습니다. 이를 활용하면, Lib9c가 매번 hack_and_slash2, hack_and_slash3, hack_and_slash4 처럼 수많은 상태 전이 로직들에 대한 들고 있던 것을 hack_and_slash 하나만 가질 수 있게하고 블록 인덱스 구간에 따라 DLL을 동적 로딩함으로써 복잡성을 해결하는데 도움을 줄 수 있습니다.

그런데 이를 적용하게 되면 각 버전별 Lib9c들을 DLL 형태로 들고 있게 되고 동적 로딩하고 형변환을 할 때 IAction, IAccountStateDelta 등 타입들에 대한 바인딩이 런타임 시점에 이루어지게 됩니다. 그리고 만약 planetarium/NineChronicles.Headless 에서 사용하는 Libplanet의 IAction이 기존 Lib9c들이 빌드 될 때 사용된 Libplanet의 IAction과 호환이 되지 않는다면 이는 동작할 수 없게 됩니다.

호환 되지 않는 경우를 예를 들어보면 만약 아래와 같은 IAccountStateDelta와 IAction이 있다고 가정합시다.

interface IAccountStateDelta {
  IValue GetState();
}

interface IAction {
  IAccountStateDelta Execute(IActionContext context);
}

그리고 위의 IAction을 구현한 Action이 있다고 가정합시다. 그리고 나중에 Libplanet을 수정하다가 IAccountStateDelta에 기능이 추가되어 시그니처가 바뀌게 되면 본래 Action이 반환하기로 약속했던 IAccountStateDelta와는 다른 IAccountStateDelta이기에 런타임 시점에 형변환에 실패합니다.

때문에 Libplanet.Abstractions를 프로젝트로 분리하는 목적은 아래 두가지 입니다.

• 의도적으로 바뀌어도 될 것들과 바뀌어선 안 될 것들을 명시적으로 구분합니다.
• planetarium/lib9c와 planetarium/NineChronicles.Headless가 서로 공유하는 부분을 최소화 하고 각자 다른 Libplanet 구현체를 가질 수 있게 합니다. 상태 전이 로직에 타입 상으로 영향을 미치는 부분을 제외하고는 Libplanet에서 변경을 쉽게 할수 있게 합니다.

일단 올리고 다시 읽어보면서 설명이 더 필요한 부분 수정하겠습니다, 궁금하신 부분 있으시면 코멘트나 Planetarium Dev에서 멘션하여 편히 질문주세요!

[dahlia]

Apparently good idea, but should the abstraction package be separately versioned from other packages?

[moreal]

Well, it may work even if it uses the same versioning policy if Lib9c bumps Libplanet carefully. I think it is better to use other versioning policies because it will be more meaningful on the side to isolate them from other codes.

[riemannulus]

이 논의는 discord 에서 이어지고 있습니다. https://discord.com/channels/928926944937013338/1098922694092804097