Try   HackMD

Dmitrii Shmatko

Overview

Full-stack software engineer

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Birthday: June 8, 1984
Education: Omsk State University (not finished)
Area of Study: applied mathematics and computer science; economics
English: upper intermediate, conversational written and verbal skills
E-mail: zilm@zilm.net
Github: github.com/zilm13

Skills

  • Backend: Java, Python, Node.js
  • Blockchain: Ethereum, Solidity, Vyper
  • Databases: PostgreSQL, NoSQL (MongoDB, InfluxDB), Oracle, MySQL
  • Frontend: JavaScript, TypeScript, AngularJS, Bootstrap, jQuery, HTML5
  • Infrastructure: CI (CircleCI, Teamcity), Docker, Automation (Fabric, Ansible), Nginx, Heroku
  • Administrative: JIRA, Confluence, Redmine, Trello

Detailed Work Experience

Developer at Harmony (December 2017 - current)

Ethereum 2.0 client. Casper FFG test client. EthereumJ (Ethereum 1.0 client) support and maintenance.

Skills: Java, Ethereum, Python

Web Developer on freelance (June 2017 - November 2017)

Financial data processing.

Skills: Python, Blockchain (Ethereum), NumPy, Pandas.

Developer at Ether.camp (June 2016 - March 2017)

Development of several blockchain products in the Ethereum network including:

  • open-source Java library and network client implementing Ethereum White Paper and developer's API
  • MVP of cryptocurrency system for major European bank

Skills: Java, Blockchain (Ethereum), Spring Framework, AngularJS, TypeScript, Android development.

Web Developer on freelance (April 2016 - May 2016)

Microservices system gathering statistics from mobile app platform and administrator frontend for it.

Skills: Node.js, Javascript, Bootstrap, ReactJS.

Lead Developer at 7bits (November 2013 - March 2016)

Portfolio Management System for US financial market:

  • maintains actual portfolio state by handling all market events: splits, symbol renames etc
  • provides financial metrics for portfolios, stocks and options
  • models and rebalances virtual portfolios according to user's configuration
  • sends orders to integrated broker to fulfill user's strategies

Skills: Python, Flask, NumPy, Pandas, Ruby/Rails, Java, Spring Framework, Node.js, Websockets, Postgres, Oracle, MongoDB, InfluxDB, DB benchmarking, Javascript, Twitter Flight, Bootstrap, nginx.

Web Developer on freelance (August 2012 - November 2013)

Various small projects.

Skills: PHP, Machine Learning, Apache, nginx, Web scraping

CEO of Dextralink Corp. (March 2004 - July 2012)

Created and scaled number of web projects in software distribution. Besides management tasks my main focus was on the fields not backed by developers strengths: DBs and frontend.

Skills: MySQL, SQL optimization, server administration, DB administration, HTML, Javascript

Last changed by 
 
Dmitry S.
373

Read more

Low participation in Hive issue

Hive counts participation in another manner, not like us.Hive participation data for 1 epoch:

Oct 4, 2022
Eth2 to Eth1 Validator's withdrawal design [WIP]

Currently Ethereum 2 supports deposits with the only option, deposits from Ethereum 1 and there are no options for validator's stack or its part to be withdrawn. We want to add an option for Ethereum 1 withdrawals following validator exit as the simplest approach for validator owners to get their deposit back with rewards. No option for partial withdrawal is suggested due to higher complexity and lower safety of possible solutions and minor losses on reentry which should take about a day. Our highest priority is to make deposit-withdrawal processes handled with maximum level of autonomy and separation of validator and funder's roles to make possible creation of shared owned validators. Concept of Ethereum shared stacking pool is created according to the specification and currently in testing. Withdrawal implementation requires a set of changes in both ETH2 BeaconChain and ETH1. Contents: 1. Changes in BeaconChain   1.1 Withdrawal credentials for Eth1 withdrawal     1.1.1 Message for changing withdrawal credentials   1.2 Withdrawals   1.3 Withdrawal processing

Sep 7, 2021
Using total difficulty threshold for hardfork anchor: what could go wrong?

[by TXRX Team, Dmitriy Shmatko and Mikhail Kalinin(link), evaluation code is here] In the upcoming Merge Fork which encloses the current PoW chain into the Beacon chain as an Execution Layer, total difficulty was chosen as a point of transition instead of a block number (see Terminal total difficulty vs block number). This approach negotiates the risk of forking a wrong chain backed by minor hash-power but could lead to other risks during transition. In this post we are going to measure these risks and propose changes to fork schema if any is required to decrease the possibility of unforeseen transition flow. Happy flow It's expected that merge client settings will be known in a month before merge happens, so client developers could update their software and validator owners could update their nodes. At some announced epoch number, say, MERGE_FORK_EPOCH the action begins: Beacon chain nodes calculates votes in the last voting period to get some major-backed Eth1Data with block_hash reference to the block in the Mainnet. The corresponding block is called anchor block and becomes a point from which merge total_difficulty on PoW chain side is calculated with the following formula (see spec): def compute_transition_total_difficulty(anchor_pow_block: PowBlock) -> uint256: seconds_per_voting_period = EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH * SECONDS_PER_SLOT pow_blocks_per_voting_period = seconds_per_voting_period // SECONDS_PER_ETH1_BLOCK

Aug 16, 2021
Purging BeaconState ever-growing Lists

In our approach for providing Validator withdrawal feature we use BeaconState List to store withdrawal receipts from processed requests and automatical withdrawal tasks. Such method assumes data is growing with the time and nothing limits its size. The obvious downside of it is growing size of BeaconState, when every non-light client needs to keep old Withdrawals in state. We propose to purge old Wihdrawals up to client settings, so some clients could store all historical Withdrawals and others could be ok with storing only latest few thousands. Also similar approach could be applied not only for Withdrawals but for other growing parts of state. Accumulators Accumulators are already proposed solution for growing state data. It works in following manner: we have circle buffer for items, for, say, 16384 entities. And we have list for old buffer roots. So, this list grows with time but 16384 times slower in this example. There are several downsides we see in accumulators and want to solve it with purging approach: Old items are still needed by some clients. There should be a mechanism to sync them, there should be a mechanism for clients to request old item which is more than buffer size older. Buffer size is part of a specification. Every client should follow it and cannot have its custom history settings. Accumulators still grows with time. It could be not an issue at the launch, but with grown usage it could become an issue to.

Jun 7, 2021
Read more from Dmitry S.
Published on HackMD