wip

projects/feature-activation/0005-feature-activation-for-transactions.md

@@ -191,15 +191,34 @@ As described before, the best block can only shift TO and FROM scenarios #2 and
 
 Given the explanations in the sections above, a new method will be added to the `FeatureService`. Here's its reference implementation:
 
-TODO
+```python
+def get_state_for_transaction(self, *, tx: Transaction, feature: Feature) -> FeatureState:
+    best_block_tips = self._tx_storage.get_best_block_tips(tx.timestamp)
+    assert len(best_block_tips) >= 1
+
+    best_block_hash = best_block_tips[0]
+    best_block = self._tx_storage.get_transaction(best_block_hash)
+    assert isinstance(best_block, Block)
+
+    best_block_height = best_block.get_height()
+    offset_to_boundary = best_block_height % self._feature_settings.evaluation_interval
+    closest_boundary_height = best_block_height - offset_to_boundary
+    state_block_height = closest_boundary_height - self._feature_settings.evaluation_interval
+    state_block = self._tx_storage.get_transaction_by_height(max(state_block_height, 0))
+    assert isinstance(state_block, Block)
+
+    return self.get_state_for_block(block=state_block, feature=feature)
+```
+
+That's all its necessary to enable Feature Activation for transactions.
 
 ## Drawbacks
 
 ### The two-week delay
 
 A drawback is that feature states for transactions will always have a two-week delay when compared to feature states for blocks, making the transaction process a bit longer. The tradeoff is worth it as this makes for a very simple implementation that naturally doesn't need to account for reorgs.
 
-Special care should be taken when designing new features that will affect both blocks and transaction at the same time, as the feature may become `ACTIVE` for blocks before it does for transactions. It's not clear at this point if this will ever be a possibility for a new feature and if it would be a problem, but if it is, I believe we can solve it by simply introducing a two-week delay on the feature state for blocks, making their states synchronized with transactions.
+Special care should be taken when designing new features that will affect both blocks and transactions at the same time, as the feature may become `ACTIVE` for blocks before it does for transactions. It's not clear at this point if this will ever be a possibility for a new feature and if it would be a problem, but if it is, I believe we can solve it by introducing a two-week delay on the feature state for blocks, making their states synchronized with transactions.
 
 # Rationale and alternatives
 [Rationale and alternatives]: #rationale-and-alternatives