From an architecture perspective, initial versions of a blockchain protocol, like bitcoin had a pretty simple architecture: transactions were put into the system that were validated by nodes and ordered into batches by the miners and the state transaction was computed as well in the same time. This architecture was further developed by smart contract systems like Ethereum in a way that instead of simple transactions, a complex business logic can be executed named as smart contract.
As smart contracts seem to be a natural way to define general business logic into a blockchain system there might be a fundamentally different way of extending a blockchain architecture. Mining or ordering service is responsible for finding a subset of the transactions that are consistent and avoid double spending. However this logic can be something much more difficult, like solving different graph algorithms on the transactional graph or even general computational algorithms like something with constraint satisfaction or rule based systems. It might be even an option to define ordering based business logic as different modules that might be dynamically configured.
In this sense business logic in a blockchain system might be designed in a two level way, similarly as in a classical software design there is client side and server side business logic:
- business logic that extends a given transaction and influences only one or just a couple of addresses should be realized as a smart contract.
- business logic that effects all of the accounts and transactions and the perhaps the ordering logic of the infrastructure as well should be realized together with the ordering service as an attachable business logic module.
