osmirnov

My week in CityOfZion - Nov 18, 2018

CityOfZion/neo-sharp

Created

• [WIP] Initial neo-vm support #546
  • Wrote initial integration with NeoVM
  • Identified missing APIs for SmartContracts

CityOfZion/neon-wallet

I dedicated some time to QA new wallet.

Created (Issues)

osmirnov

CoZ Bounty #1: Alternative Consensus Implementations - FastBFT Submission

I present FastBFT implementation of the consensus algorithm as a part of "CoZ Bounty #1: Alternative Consensus Implementations" program.

Why did I pick FastBFT to participate? I was not familiar with this algorithm before. I expected to see multiple submissions of HoneyBadgerBFT and decided to implement any other BFT algorithm. At the end of the day, NEO community will benefit from having of many consensus implementations in its disposal. Meanwhile, could I state this is the world first open source FastBFT implementation? 😉

Before diving deep into FastBFT I would like to talk about the current consensus algorithm used in NEO network.

Delegated Byzantine Fault Tolerance (dBFT)

Today NEO network is using Delegated Byzantine Fault Tolerance (dBFT) algorithm. The next steps are executed by replicas to achieve the consensus on incoming transa

osmirnov

My week in City of Zion - Apr 15, 2018

CityOfZion/neo-sharp

• Isolated DI and treated it as an infrastructure dependency CityOfZion/neo-sharp#30
• Refactored UInt160/UInt256 data types and removed UIntBase CityOfZion/neo-sharp#32
• Cleaned up code issues and introduced coding standards via ReSharper shared team settings CityOfZion/neo-sharp#36

osmirnov

My week in City of Zion - Apr 8, 2018

CityOfZion/neo-sharp

• Restructured projects, isolated abstractions and implementations CityOfZion/neo-sharp#10
• Wrote design spec before NeoSharp Dependency Injection (DI) Design
• Assisted @daghdha with coveralls integration CityOfZion/neo-sharp#12 (comment)

osmirnov

NeoSharp Dependency Injection (DI) Design

In current design there is a DI folder in every project that contains Package class. This class accepts Container class as a parameter and performs the registration of dependencies. NeoSharp.Application composes of all "Packages" passing a root container to each of them sequentially. Such a straightforward approach has clear limitations.

1. Every project is dependency management aware. It has to register its services in some container and to make an assumption about their lifecycle (Singleton, Transient, PerThread, etc.). Both of these things are bad. The former defeats Single Responsibility Principle (SRP). The project has not only the goal it was designed for but also a sub goal to register itself in the external container. The latter will bomb when multiple consumers of the same project have different requirements for services' lifecycle.

2. Every project references SimpleInjector dependency management library and cannot be used without this. In case of the DI