search

multiversx / mx-chain-go

⚡ The official implementation of the MultiversX blockchain protocol, written in golang.
https://multiversx.com
GNU General Public License v3.0
920 stars 199 forks source link

[Bug]: DEVNET - DSC with 40 BLS keys and over 50K xEGLD will not activate more than 11 Validators #6299

Closed frankf1957 closed 2 months ago

frankf1957 commented 2 months ago

Contact Details

frankf1957@telegram

Description

DEVNET - DSC with 40 BLS keys and over 50K xEGLD will not activate more than 11 Validators

Node version

D1.7.13.0-0-0-g6947001/go1.20.7/linux-amd64/f4f209cdca

Host machine

Hetzner

Steps to reproduce

This is a multikey setup with 4 observers running on a VPS hosted at Hetzner. There is no issue with the VPS, cpu util is around 10%, no memory or disk issues. I have monitoring and alerting configured with no alarms or warning having ever been issued.

In the DEVNET explorer we can see my 4 observers running if we query " Maple" << no quotes, but notice the leading space. In the DEVNET explorer we can see the validator and observer nodes created by the multikey setup if we query "maple-leaf".

I created a DSC using the web-wallet. Contract address: erd1qqqqqqqqqqqqqqqpqqqqqqqqqqqqqqqqqqqqqqqqqqqqq80llllsrepk69 Owner address: erd1ukwvdvxwd0ln9s9e95tcymutud042vrzmsezvrjugq7caly065us6hmule Deploy transaction: 5b182d6f428122a7e4074441c63530983f85bca7015a738d75bc11a6f46b7ecc

Use web-wallet -> Node Management set the following: automatic activation = enabled redelegation cap check = disabled service fee = 0% delegation cap = 0

Added 40 BLS keys to the DSC.

Gradually delegated to the DSC from 2 wallets, 5k xEGLD per transaction until each of the 2 wallets had delegated 25k xEGLD each for a total delegation of 50k xEGLD.

Only 11 validators have been activated. And it has been like this for many epochs, always 11 validators.

When I use the web-wallet -> Node Management, I see “Number of Nodes” = 40. In the “Your Nodes” section I see “Selected Nodes” = 0/40, but as I count them I count 25 nodes on page 1, and 4 nodes on page 2. Total is 29 nodes.

Is querying the DSC via the API at endpoint “/vm-values/query” still valid? This query presents yet another view, albeit one that I tend to agree with, as you will see.

Here is that query and the result set. 

$ bash sp-vm-getAllNodeStates.sh 
call /vm-values/query with function: getAllNodeStates
# curl -s -k --data "{"scAddress": "erd1qqqqqqqqqqqqqqqpqqqqqqqqqqqqqqqqqqqqqqqqqqqqq80llllsrepk69", "funcName": "getAllNodeStates"}" https://devnet-gateway.multiversx.com/vm-values/query

returnData[]
[
  "c3Rha2Vk",
  "WVkC/NfTVHPWLqPbCICMU+xRWNeQV9Dc4gkliqeod0eMXbNl/ezYz6UR5toaKYID6HVirXbc9xJkw5txFxCLw2ZVj7HylNaH9puVWSvIrao9X7T7Sc43AW/OGDhTSc6R",
  "WVkEbs4X84sC7fb/DK8wueRfU8ramMOx41NnvGYaUDhc08gZx3fPAaVPnKQ/Ka4EYRgc36LAIng4huDaafFDui6/u26GUtxD/XSZiyG75YRv3ukfRPD3NmcLI0k7IFyY",
  "WVkGMqrKjnT7rxQGW8yOrw+qjP0MSnu06fAn07DEto21wujfUVLctt594upr/0oARMPCjd9FYrkHAz8C3xfGPJt7HVG4YYwd8/3HBOty9Zs7Xzm3LODw/WCr/voYYsUS",
  "WVkOqZ+BwmNl5hGvKf5i+c4Ycyj9d1fRcPVuh2db/pd+UH+NYxpxjRPrfkVO2VUZV9Z1941H6FmeHd4VVauUwOt3H93ueEfjwV4ATwoPjCuv7zU2flIcZBzMR8NjvWaO",
  "WVkSotKvf+JDLSxB1/giM/gIUZjROODq3g3HLmzk+gT/nBnjhX/pvCfNR1mWulETQWLG1KwkAyYL+IVg/7lL0ncpWs9nUJy9VGCAZNP3M24xOhQPWAK5tckGH2i4gpOH",
  "WVkUr/sTBg6BAdsc3c9xW24OvqtgKYh/wYUIg+mZAYXfFo7n+W+s01msfyQvEHwBTrJ3PYNx4SE+eYuzJ76wi1bVHgOXvt5CepaGXwcttLAENuYTLtdr0GekiksbHq2I",
  "WVkYKI6rjnOZmDjDSOGpcU0BZSbRm6IeCubtDkbTGf/MseYuSbrISTI26uldyMkFV7c68JZKdhgNZNue+5nqjYxIxJ+R51QFyGdNjXpSuRemyar61uuAROJ6W5FgJuuU",
  "WVkclmmWkIDNxT9GYH/q2T0bI0hMt1GHwg6YTEExUyzbdcY7EF3f3hW8dK/SGbkJAFZYtjlQ7gZoIYO4U4Irp74EkPHVe+fx2FPg2lTTSSQj2MJgUqsruOYRLsI4GRcG",
  "WVkq2BbRcWd0bqWn2FuD5W+WzPIQ2e3lQvKeJBqgJQG/VwZL2GzRccBgDYVu8ugQNiCiVYWEP20osCpA95JL1zIDeLHjIS7GqaUy/HV5EcXW2X5uenTJ8VgAa/ASsNsA",
  "WVksAcHarbdtFAedSnqa6YvvOhm98P472cf/Clbfn/5IYys5LcOgSrOX6PrHn68PzDanf16FH3mR4SIwwhou20ebtFFnxqDFITNZ33HoOGB69x7JXihA/wyKnGTRvg6N",
  "WVkual2G8CJrCqeORiLOYTI7Jv6c/YXD7QAF+gTCu2lAsOc+uoaUb4xvKmGM2RgPaFO+Q+ONsI320kEmGwpAfd5zCJiXvac4gGsk7vRJRv5/V1VGCayrwdZMTfObHagP",
  "WVkxW2Heunnt2Xald/N/HdiRMjLeWXY+RZRSj9x14pZ1+eEKG92HrCiPHJ0UETERnRK4nftxFYoSgAMUtCEs5ZSpfYmwJKXQX0d2bl7J231jEZqe/cBjD+g1PXaaPfSI",
  "WVkyIIDSqY4xzTwwa/9O5FUJHLVjIlfoLm9O7mAEq7tOq2qQ2d+5tpu3WMGAHxsEE2SXsypR/qDpxAHilnTl4OjN6bJmNAKkwMAQy6AnPZP5zSAZRi+9QVHR298HSmqY",
  "WVkzJcjcBoZgKrMdzZUuiOhMM3C+p9ZNiCPQ/Hhxo/bGpykexuD+GdzaEu1r+ycQU0wlsu36PL3HGqnMR9NTUGv93z2CapvewUtEOw9OkblLqDPJA1u+z3SDRzlmCcQU",
  "WVk8ePinLe8uDla1Dbk6xxmMKwAaoxw5jckdrCcZ06mKtHS+k9dNwc8uXq0zdDcH2NJqvKE13NIKCSFUfbh+yYAhh1X69cd/OKit+ps/DTmRR8ZwlYQceOx9GDNHZCWU",
  "WVlFwkypTwiQbJpYXiRRSMnP8FXl+Qo2TTTBbpV2pd9LycpVZBssgQmpaNQEOTIDfWJ2YYotwATNtr63uWmLHvJTPdq8NqGlIA59FCXKk/4pU+Cg3mI6NNqqUuR0RRmQ",
  "WVlGl8TS5tS/O+gGGgmOWV1Evls1Kgnzt/LUpbzDSA1IZ55TmGcPD3PpoS4jncYTUqxglbuJvz5ZLEW7Z6EJCiP/3PUIyn9Rj8JK69RwPt5bGoIGCgJla6OPKZfH+naM",
  "WVlGrQ94WkxwgXbeUQxoceS33xp1ZcIB/kT1qT+GM0TA0mEZN5p7lJ7eOJdm8MkHoOGoCkL6SYEuASzDwtwVHeWhbvoNEuLpB1I0BW35egEe4wgiiBLCE7ongcYhSECV",
  "WVlHoFyu5gBM+3yCaW0D0BlGcIFkZe3dGea3XBPBLYzSM4vOGY7mHuQOOxugKZoTM8kolpx3rFyO2gpQX5fTrVNE446mNFH3exzGyshFbXbVpaxHYtLhwxb4nFJ1A4sM",
  "WVlJeYvRD1o+Jo5hvp+wPzZoObTGyfDBpANF2gCvDkoZbD9kQaNDtSYTamwkNpEZ145Y/i9NRgS7SxUgbbr/MJhPGHzSoWuVccMn/Y8EI6NMJb/2PfnZqyjWv/epzsYJ",
  "WVlRRF8Wvw7sNtSa1r7AIRqasViMuwS8ol6HsV4isNU0lrr9dV52K5+xand0zEAGcht7kO9HegwJq9oDhLhG6gBxqAUv0dW6UH5GUEn2+QTqMUrPdUf9lwqfPZjUn6AX",
  "WVlVqlP68x+Dlfog/DfUKDK1NCNFTK30plgQOnVJgiZ0ngnBMQ9MnKr6E4E+d5MCzS5USi1kg8pa67K2jtthXVmvLbIvjcZtH3Kz1Au9TBH3kMJTiYdm9TvWg2Z1DsCW",
  "bm90U3Rha2Vk",
  "WVlXA9vW9WgZPurRuczVFId+Wq9wKlsXBPpl37/7eA4eMiD8rlpf7taNoPgV99AG+2gm7S9nwgFpFrrcbDLBbAfUw5/JZI9fryrJ9xX1IREEshKkPUa7Uur91sX+LjqJ",
  "WVlcca8xEXTNBIj4Rk0J/IRNDDOTklmywn0b73+MBv6EnXuRDs+1eFpl/oOpd+ABO0rrQt8Ggps6I0jEpo578e28Uf6QeKo8yJqFeRnL/g6y7XPIwdcZfpl3b8yrV7SY",
  "WVlyzMaMxd5iHappJ4/4F226uhjkWXLpLPYM6k4ueu3M++OIh+HJvZTBcj3UHlkX4zupi0TQWh9DL/xK5tYkFU4AoUQMSKzfu7QHRwqxpQDQ1lRLtEhCbmOKCXifaK2W",
  "WVl1mgKjlqoQbrMrvngLJLZjfjUjO/ggfVZeyb+uUcbDUxDQEI9T/kBudPKJl9gRkkLULPygZD/2MxLxIgkuxjPaorSD8HRaCQASnopGRnitc/RjDM0OOJ9VCbRbeLUK",
  "WVl1pOW10hnHfAouQDxDY7+sYIPWkyQ8yyf9ZXvpSHgrcR3cCA6gbZby4W42l/YIneZEUiRhl1nr6u7XeiMAZPGvgbSt5q7VnjKhAt39pAwrf0Dn22ZezK+CakE7wTMJ",
  "WVl2cekGHSZHfW63ewepDS5XBAzZD55lYL15AOYkPdiO82dJ3YyVM3HfOoHZoJgMVWk3kD2MclGDfb2KUeByJvIf9ckDpmg3ZqWU8tDEWBGPustLEl3IS+IkBDT6CLMN",
  "WVmZx5RzlPFV5mBVSkrkNC/BbTwpei+lCWWcBoEQdxZ55rbKgGSj8d7jRbqQSgUPey2XTvAbHCuJJ7T6GITdZSq/H49I70yrYMLBiVTbMVZPdUyk0xKhzFJqxkoTc+4A",
  "WVmee8HC0I28acCNxAGw/PQRrIhm2WgeVmTchLSXZhj1gJTfcTn5shniazhfJfMC8+LW5RIvmA3GQlN1xXXaPoYCHSMw3VIu0bwFhFi53gXZ5SY/WqCMBiVlpOkN6qyT",
  "WVmiYpn8TjFmVGRku1ptKu5rqKvniEbYRuYGb99LXKDNgpVJNeOel4Afj7b/0DgIb+q6d6IOflBhDyC41bn1Iv9xnaTshMwQeXwJBMO5/Aul1JXNLxrwUVlFLupuZpER",
  "WVmj7R2nWOlfGvmB+qvLJiDpBG66E0EAJU72/c5tCTCOqZ8sOarwTxFMj2srZx4JT0bNtwBTQ0+J047SoIN9LiPrwqh2ByP9Aw16BZK61TNDqLotjxSJk5lV5CQnrfuS",
  "WVmvj4nvKVKTP2QFZEgj4N4tHuh0bQzX9Vekc88gjJro+wW+RHmqfEDe/4ouqO4IMWGoehVx4YrGMiYza1Ij4V3cy6BQVao/8bUREeWU7qYipcfdWkTFIPmdJMxxodKA",
  "WVm6tUFpZnOHt7974aUv4S9DhjcYVeJClQtZ5izP2Q/yZNUw7Naj5u2VQGGi8DUKKoQA4BexrPMft/TFIT9qJYoggvDJbNGYdpoP1lLMe+TErs+mgPOoG85c1X0ODI0S",
  "WVm/flvqtm7Y5zja8T/VF/IyRbk3W+QcW0XqFioyhZBcRWWC2EDGDkzWBL3DCQsWtyMN9XXONCYPEVdxuPopB5P4uk7Fx644tWD57RF84miih57xnhc1ovo/RvQoQd0N",
  "WVnDHYFkpn8No/l5a88m+5LQBT4ZxIFA/kt9HhWFt0i4Mwstybs1V9333Dm4jx4LtGqLu1R19bZAPQq7QZwzVFahGGj+xqO9j3CwLggBXH09leR8JBTs0q8Wjp4ylKeY",
  "WVnUWnK9TFcOr6aouwM0w8iQSJ3V0wWxN9WeeM1GYIBqpST6y/Sss3xy6TNMfe8LigtXd0zRcRMbKW3A2+C3PllNLYzsXBllnczautQ7fRfpR9BFR1K4bD972uDsOB+I",
  "WVnw2Up5XPwwbVEsbmwyHegTmi7wW0qirFj0blVE9jKpkVVJZIbcK49AXDQ0bZ4PICsCEVnr8XzOVbM4wuQqUL28J5K5jtmOTGyWf8Fkg8WMM5nR1KbK2D/yF87YGBSW",
  "WVnx8RRmQKSNKGERPMIFKyzzG50kSG1dcoudtlsxlQ2ic+ARNHokW3vmJb2cWUMRWnuWYPlXxWJ5JCUIlhhN/D6T82YdsLR/VtgMHjDMppowHPilkKBPVC1O4aF1ta+U",
  "WVn7vJF2MiwS/7beGJsgbOCIiS/hE+dfNp4R6OZidaC7DgLzPW6vExv4RBl8YlAQ6Z3pQ4ktm+qbSTdYZ4z+/GLRQtt7pcMf1u+pkXRkfw6/u6fM64+xpworW1AjDiET"
]

In the results output from the /vm-values/query we see 22 BLS keys are in state staked and 18 BLS keys are in state notStaked.

This view looks accurate to me, and is what I expected. So, how then are there only 11 validator nodes activated?

I will post screenshots of what is seen in the web-wallet -> Node Management view.

On which network is the bug manifesting itself?

Devnet

Relevant log output

No response

Code of Conduct

frankf1957 commented 2 months ago

Screen Shot 2024-07-06 at 12 38 29

frankf1957 commented 2 months ago

Screen Shot 2024-07-06 at 12 39 16

frankf1957 commented 2 months ago

Screen Shot 2024-07-06 at 12 39 44

frankf1957 commented 2 months ago

Screen Shot 2024-07-06 at 12 41 39

frankf1957 commented 2 months ago

Screen Shot 2024-07-06 at 12 41 48

bogdan-rosianu commented 2 months ago

Hello, @frankf1957 . Thanks for opening this issue. As you might be aware of the 50 nodes / entity limitation on Mainnet, this is the same mechanism but applied to the devnet numbers. As defined here, NodeLimitPercentage is set to 5%. The protocol computes the max number of nodes per entity by multiplying that percentage by the number of total eligible nodes, resulting in 5% * 232 = something that rounds to 11 nodes.

Hope this clarifies the situation

frankf1957 commented 2 months ago

Hi @bogdan-rosianu , thank-you for the update. Will close as resolved since this is not an issue.