Stake 2.0

[superggn]

Will tronpy support Tron Stake 2.0(Now Nile has already opened functional test for Stake 2.0)?

ref: https://github.com/tronprotocol/tips/issues/484 https://coredevs.medium.com/what-is-stake-2-0-e04f59b948a6

[MrNaif2018]

Hi! What exactly needs to be done to support it? Just the new API endpoints in a more official way than the provider.make_request route?

[superggn]

Hi! Thanks for your response, I think support for apis in this link would be good enough, since the old version of staking is soon about to deprecate

We usually test our code on Nile testnet, and Nile testnet has already started Stake 2.0 test.

Our test code is like this

from tronpy import keys, Tron
from tronpy.providers import HTTPProvider
from tronpy.tron import DEFAULT_CONF

# client
client_nile = Tron(network='nile', conf={'fee_limit': 10_000_000})
end_point_conf_public_node = {
    "fullnode": "http://...:8090",
    "event": "http://...:8090",
}
main_net_provider = HTTPProvider(
    end_point_conf_public_node,
    DEFAULT_CONF['timeout'],
)

# Example code
addr_1_base58_str = 'TUL8FVTtthisisfortestthisisfortest'
addr_1_priv_key_raw = 'fbec0b2ad09fthisisfortestthisisfortestthisisfortestthisisfortest'
addr_1_priv_key = keys.PrivateKey(bytes.fromhex(addr_1_priv_key_raw))
addr_1_hex_str = '41c9670882134323thisisfortestthisisfortest'

# stake trx (old version)
amount_freeze_sun = 100_000_000
txn = client_nile.trx.freeze_balance(
    owner=addr_1_base58_str,
    amount=amount_freeze_sun,
    receiver='TQXszq5VsjVEqytTthisisatestaddress',
).build().sign(addr_1_priv_key)
txn.broadcast()

# unstake resource
txn = client_nile.trx.unfreeze_balance(
    owner=addr_1_base58_str,
    receiver='TQXszq5VsjVEqytTthisisatestaddress',
).build().sign(addr_1_priv_key)
txn.broadcast()

when trying this on nile test net, we can get the response below

...raise ValidationError(msg)
tronpy.exceptions.ValidationError: Contract validate error : freeze v2 is open, old freeze is closed

[MrNaif2018]

Oh I see! Maybe those methods would need to be updated to the v2 protocol. What about the legacy apis? Will they no longer work, or some people might need it?

[superggn]

About the lagacy api, the "stake"(freeze) api will be deprecated once they got Stake 2.0 online, but the "unstake"(unfreeze) api will still be alive(working) for some time, for letting users retrieve their staked trx in the old way.

[MrNaif2018]

Then I think we can make the methods use v2 APIs, and introduce smth like unfreeze_balance_legacy for V1 unfreeze and maybe make a release at the time it gets live on mainnet?

[superggn]

Yes, that would be cool! I'll keep an eye on when it's going to release on mainnet. BTW here's the telegram dev group, thought you would like it. Tron's got lot of official guys there.

[MrNaif2018]

Please try out 3692779da3a651568f750bc8430512eabd69cfff

Not yet sure what to do with the receiver param, as 2 transactions are now needed, backwards compatibility can't be preserved

[superggn]

Hi! The updated apis works good! However, there're still some apis need to be supported. Now Stake 2.0 tears the old stake operation apart into "freeze" and "delegate", as you just mentioned "2 transactions are now needed" The receiver param goes with the "delegate" part

For "freeze" part, user can freeze and unfreeze trx to operate resources (bandwidth and energy) between the trx owner and TRON. For "delegate" part, user can transfer resource between owner address and receiver address, e.g. owner transfer it's energy to the receiver address. And here is where old "receiver" param goes.

Old "freeze" -> New (Stake 2.0) freeze + delegate Old "unfreeze" -> New (Stake 2.0) undelegate + unfreeze

So, in order to get the minimum usage, we need like 4 more apis (mentioned here):

/wallet/getdelegatedresourceaccountindexv2 /wallet/getdelegatedresourcev2 /wallet/delegateresource /wallet/undelegateresource

Actually there's 10 HTTP APIs introduced this time, it would be fabulous if all 10 APIs are supported by tronpy. However, if we have to pick a priority, the 4 APIs mentioned above are a bit more urgent

[MrNaif2018]

Yeah, it's not a problem. The only concern for me is backwards compatibility. I guess we drop receiver param and introduce new methods for delete/undelegate?

[superggn]

Totally agree. Compatibility issue should not be a problem by marking the new release as a major update.

PS: About the timeline, as you can see [here] (https://github.com/tronprotocol/tips/issues/519), the Stake 2.0 timeline is about the middle and late March.

[MrNaif2018]

Out in 0.4.0!